bug#65209: 30.0.50; Unexpected behaviour of setq-local

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  65209@debbugs.gnu.org,
>   gerd.moellmann@gmail.com
> Date: Thu, 24 Aug 2023 03:06:32 +0200
> 
> > IIRC this is done purposefully (the code has to work harder to get this
> > semantics), but not really documented, and I can't offhand give you
> > a good reason for that semantics.
> 
> Thanks for the example.  (info "(elisp) Creating Buffer-Local") says
> about this case
> 
> | Making a variable buffer-local within a ‘let’-binding for that
> | variable does not work reliably, unless the buffer in which you do
> | this is not current either on entry to or exit from the ‘let’.
> | This is because ‘let’ does not distinguish between different kinds
> | of bindings; it knows only which variable the binding was made for.
> 
> I would really like to know a bit more than "doesn't work reliable".

I don't think we should tell more about it in the manual.  When the
manual says "doesn't work reliably", the meaning is clear: stay away
from doing that unless you know very well what you are doing.  So if
someone wants to use this regardless of the warning, and they don't
yet "know what they are doing well enough", they should either study
the code or ask some expert.  Such subtleties have no place in the
manual, since that would make it very large and hard to read for the
majority who will indeed "stay away".

> Such situations happen in real Emacs life.  It's not always under the
> control of the user or the programmer which variables are currently
> let-bound when a buffer is created and buffer local variables might get
> set.  "Anything can happen" leaves me with a very uneasy feeling.

Please describe such situations, where the escape (i.e. how to avoid
bumping into this subtlety, by either rewriting the code or using
auxiliary variables) is not clear.