>> +** 'setq' displays a warning when 'customize-set-variable' should have been used.
>> +Some custom variables need to be set with 'customize-set-variable', because
>> +they were designed to be set through the Customization interface and have a
>> +:set lambda form which does other things after they have been set.
>
> I thought the conclusion was that most variables with :set can be safely 
> set by setq, isn't that so?  If so, these warnings will mostly annoy.
>

No, that wasn't the conclusion.  Most variable with :set can safely be set 
by setq *before* the file in which they are declared is loaded.  And no 
warnings are displayed in that case.  But all variables with :set cannot 
be safely be set by setq *after* the file in which they are declared has 
been loaded.  And warnings are displayed in that case.

>
> What will happen if setq is in the user's init file?  We generally delay 
> warnings until after the startup in those cases.
>

With the following .emacs:

(require 'allout)
(setq allout-auto-activation t)

a warning is displayed, but I don't know if this is during of after the 
startup.  At least it is visible when startup has completed.

>
> Also, warnings.el is not preloaded, so this call could barf in some 
> valid cases.
>

That's not what I see:

;;;###autoload
(defun display-warning (type message &optional level buffer-name)

>
> OTOH, setq is a primitive written in C, so ther should be no need to 
> call intern for it.
>

Okay, updated patch attached.

>
> And finally, do we really want to slow down each setq by calling intern 
> and Fget?  setq is many times used inside tight loops.  I'm not sure the 
> resulting run-time penalty is justified.  Did you measure the effect of 
> this on performance?
>

With the updated patch, on my laptop, the execution of setq takes ~48 
nanoseconds instead of ~40 nanoseconds.  Which seems reasonable.