bug#33414: [External] : bug#33414: 27.0.50; inhibit-changing-match-data can be t in syntax-propertize functions, breaking backtrace and looking-at

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

> Yes, using a public dynamic variable (i.e., public global mutable
> state) to influence the behavior of a function is normally a bad idea.

Define "normally".  Yes, it presents problems.
Lots of things in a language like Lisp present
problems.

> Effectively, the dynamic variable becomes a hidden parameter to the
> function, and robust code has to bind it explicitly do override any
> surprising binding up the call stack.

Correct.

> You normally don't see such a coding style in
> other programming languages,

You don't see _lots_ of Lisp things in most other
programming languages.

> and ELisp would be better off without it, too.

Even Common Lisp is better off _having_ it.  For
Elisp that's 1000 times truer.

Users of Emacs as an interactive application,
an editor (and more) _use Lisp_, including to
customize out-of-the-box behavior.

Elisp's designer - and Emacs's designer - pointed
out the reasons why dynamic binding is important
for Emacs Lisp, _in particular_.

https://www.gnu.org/software/emacs/emacs-paper.html#SEC17

https://www.gnu.org/software/emacs/emacs-paper.html#SEC18

Those reasons are as important today as they
were when that was written.  Elisp invites and
encourages user tweaking - with Lisp - the OOTB
code.  Monkey patching is part of that, in spite
of its negative connotation, and in spite of the
(quite real) drawbacks.

Lisp (even for batch uses) has a ton of things
that offer both possibilities and drawbacks.
Lisp isn't Haskell. (Even Scheme isn't Haskell.)