bug#70784: Abolish string resizing

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> The Elisp ability to resize strings is high-cost, low-benefit, so we
> should abolish it.

What is the improvement to be had by "abolishing" this immemorial
feature?

If it's a notional increase in Lisp evaluation performance, please stop.
Emacs Lisp is not a hot-rod where crucial, fundamental facilities are
dispensable in the face of a performance improvement (which is anything
but a certainly at this early stage) of a few percent or similarly
marginal value on contrived benchmarks testing scenarios unlikely to be
encountered in real Lisp code.

MPS is no justification for degrading the capabilities of the existing
GC, if for no other reason than its being inoperable on systems beyond
the limited selection whose support its developers consider a priority,
and the increase in memory consumption it brings (e.g. it will never
function on Android 13, because the C library's sigaction wrapper is
insufficient to enable MPS and JVM trap handlers to coexist).  What's
more, memory consumption is an aspect that should not be sacrificed for
minor gains in performance, with a program that is designed to be a good
citizen on systems old and new.

Is it only I who am tired of these proposals for complete upheavals
that, somehow, Emacs has fared just fine without, for generations past?
It's precisely this attitude that begins to inspire thoughts of
departure.  Backwards-compatibility is an obligation that cannot be
evaded by means of warnings, which instead serve to annoy and antagonize
users, whose only wish is that Emacs leave them in peace.