This page is part of the web mail archives of SRFI 118 from before July 7th, 2015. The new archives for SRFI 118 contain all messages, not just those from before July 7th, 2015.
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.)