bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results

[Drew Adams <drew.adams@oracle.com>]

> > (defcustom time (current-time-string) "the time" :type 'string)
> >
> > Then try to M-x customize-options RET time RET, it will show with
> > state "CHANGED outside Customize." Similarly, doing <f1> v time RET
> > shows the "original value" as the current time, not the actual value
> > when `time' was defined.
> 
> Why is this a bug?  Seems to be expected behavior to me.

Noam can provide his explanation.  For my part:

1. The "original value" shown by `C-h v' is not the original
   value.  In fact, it might never have been the value of the
   variable, and it might never become its value.

   This much is a doc problem.  What is shown is the result
   of evaluating, in the current context, the original,
   defining Lisp sexp.

   And if this is really what we want to show then it would
   be good to also show what that Lisp sexp is.  If it is
   large then provide a button/link to show it completely.

   And it might be good to also show the actual original
   value, i.e., the value when the variable was first set,
   however it was set.  (The original value could have
   been set without evaluating the original Lisp sexp of
   the defcustom.)

2. Is it not a bug that Customize tells you that the value
   was changed outside Customize?  In what way was it
   changed outside Customize?  In fact, it was not even
   changed.

How about the reverse: Why do you think this is not a bug?
What is expected about the behavior "changed outside" or
the behavior of saying that the "original value" is something
different from the original value?