bug#30101: 25.3; defcustom does not clear old :options when reevaluated

[Tim Landscheidt]

If one evaluates first:

| (defcustom tmp-test-variable2 nil
|   "A vowel."
|   :type 'alist
|   :options '("A" "F" "I" "O" "U"))

and then changes "F" to "E" and evaluates:

| (defcustom tmp-test-variable2 nil
|   "A vowel."
|   :type 'alist
|   :options '("A" "E" "I" "O" "U"))

the resulting customization page looks like:

| Hide Tmp Test Variable2:
| [ ] Key: E
|     Value: nil
| [ ] Key: A
|     Value: nil
| [ ] Key: F
|     Value: nil
| [ ] Key: I
|     Value: nil
| [ ] Key: O
|     Value: nil
| [ ] Key: U
|     Value: nil
| INS
|     State : STANDARD.
|    A vowel.
| Groups: Nil

i. e., it is the superset of the :options of the two calls.
This is unexpected and undocumented.

AFAICT, this behaviour stems from lisp/custom.el's:

| […]
|                 ((eq keyword :options)
|                  (if (get symbol 'custom-options)
|                      ;; Slow safe code to avoid duplicates.
|                      (mapc (lambda (option)
|                              (custom-add-option symbol option))
|                            value)
|                    ;; Fast code for the common case.
|                    (put symbol 'custom-options (copy-sequence value))))
| […]

which has not been substantially touched since the initial
revision (d543e20b611fc289b174aa82cab940d873a586ff).

Is there any harm in always putting the copied sequence un-
conditionally?

(Workaround: (put 'tmp-test-variable2 'custom-options nil).)