I agree that use case of fixed-size mutable string is very
limited, and it will be trivial to implement these procedures
if the implementation has some indirection.  In fact, Gauche
uses utf-8 internally and it already handles (internal)
length-changing mutation by string-set!.

However, I doubt it is generally useful enough.  In Gauche,
string-append! and string-replace! would cost exacty the same
as (immutable) string-append and string-replace, since
internal string body is immutable (hence we allocate a whole
new string body, and just switch the pointer of the original
string object.)  The main reason is because we don't want
to mutex for every string access---another thread may be
reading middle of the very string to be mutated.

There can be other choices, but I suggest that a portable code
shouldn't count on that mutating operations is any more efficient
than immutable solutions.

Then the only advantage is that the you can keep the string
identity while mutating its contents.  I personally don't feel
like I'd need such a feature, and if I ever need it, it'll
be trivial to roll my own indirection.  If there's a popular
use case I'd like to know.

Surely we already have string-set! and string-fill!, so we
could say we already eaten forbidden fruits and why not more.
But I'd rather want to see mutable string to be fade out
in future, instead of encouraging their use.

(This is srfi, so we can argue that we have it anyway and
let users/implementors to decide.  In that case, I'd like
the document to note that whether the mutable procedures
are more efficient or not than immutable ones is totally up
to implementation.  Moreover, I don't think the example of
string-append! to build a string is a good one, although
it is a popular idiom in many LL languages---I don't want
Scheme document promoting it.  String ports should be just as
easy for this purpose and probably more efficient for wider
variety of implementations.)