Re: `aset` on strings, changing the size in bytes

[Eli Zaretskii <eliz@gnu.org>]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 7 Sep 2018 16:12:07 -0700
> Cc: emacs-devel@gnu.org
> 
> Johan Bockgård wrote:
> > According to the documentation, that is already an error...
> > 
> > (info "(elisp) Modifying Strings")
> 
> Cool! That means we can do Stefan's request simply by reverting Kenichi Handa's 
> patch that introduced the ability to change the byte length of a string (commit 
> 3c9de1afcde82a99137721436c822059cce79b5b dated 2000-07-21 06:45:30 UTC), since 
> that patch made the code explicitly disagree with the documentation. Though this 
> leaves open the question of why Handa made that change in the first place.

What's the justification for such an incompatible change, though?
This feature _is_ used, e.g. see ruler-mode.el.

I understand that the effect of the change will be that whenever one
wants to mutate a string by replacing a character, they would need to
cons a new string, with the likes of

  (setq str (concat (substring str ...) new-char (substring str ...)))

is that right?  Which means in practice that 'aset' will need to
generally disappear from string-processing code, because in practice
it is impossible to know when the byte length will change without
complicated calculations, so robust code will need to drop use of
'aset' for strings, except in a small set of specialized situations.
Is that what we want?

Or maybe the proposal is to modify 'aset' to do the above under the
hood?