bug#65555: 29.1; Please un-obsolete buffer-local-value as a generalized variable

[Adam Porter]

Hi,

In 915efbff9833ea36aeb364e032a639391516912d the BUFFER-LOCAL-VALUE
function's generalized variable forms were marked as obsolete.  The
discussion happened over a few years in bug #26624.  After a delay of
4-5 years, the obsolescence was finally marked in the aforementioned
commit.

I understand that there were some non-obvious side effects in edge
cases.  However, in common cases, the generalized variable form is very
helpful for writing more concise code.  For example:

  (setf (buffer-local-value 'ement-notifications-retro-loading buffer) nil)

...is more concise than:

  (with-current-buffer buffer
    (setq-local ement-notifications-retro-loading nil))

It also expresses its intent more directly, as it's clear that the only
purpose of the form is to set a variable in the buffer rather than
anything else that could happen when the current buffer is changed (i.e.
in context of more code, the benefit is more obvious than in this
minimal example).

As far as I can tell, the objections to the generalized variable
(i.e. the edge cases with non-obvious behavior) were theoretical in
nature, without any concrete problems being noted in real code (that is,
the report was not of a bug encountered in actual use).  In
contrast, in several places in Emacs's own code, forms were rewritten to
be more awkward as a result of this change, without solving any
problems in the changed code.  And as I've noted, there is Elisp outside
of emacs.git that uses (and would like to continue using) this idiom.

As was mentioned in the discussion on #26624, rather than obsoleting the
code and removing a useful feature from Elisp, the rare, non-obvious
behavior related to using CL-LETF could be documented as an
idiosyncrasy, like other rarely encountered rough edges in Elisp.

As well, late last year I asked on emacs-devel that the
mass-obsolescence of several generalized variables be reverted, and I
was asked to individually request specific ones to be un-obsoleted.
<https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01406.html>
I can't say that I will be able to find the time to make such a
comprehensive defense of all the ones I would like to keep using, but
please consider this to be at least one of my responses to that request.

Thanks for your consideration, and your work on Emacs.

Adam