You have a point here.
There can be design errors of R7RS-small. Do we have to live with them or can we correct them? By the charter, the initial idea was seemingly to develop both the small and large language in parallel. If this had happened, we wouldn't have had the keyword syntax problem and, maybe, the string problem as well.
Hmmm... I didn't mean to deprecate/obsolete the old API or the old mutable strings. In fact, I would extend their mutability. At the moment, we do have R7RS-small strings that have two problems: (1) They are not immutable, making most code unnecessarily inefficient. (2) The are not mutable enough.
By (2), I mean that if you ask for mutable strings, you usually want more than just the ability to change characters in a string. For example, you want to be able to delete or insert characters as well.
If we narrow R7RS-small strings so that problem (1) is solved, we violate backward compatibility. On the other hand, we can easily extend R7RS-small strings to something that, say, can eventually represent Emacs buffers, thus solving (2). If we go this route, we need some new name for immutable strings. We would end up with "texts" and "strings", which would probably be named "strings" and "buffers" if we didn't maintain backward compatibility.
Even in the case of maintaining backward compatibility, I would propose some reader flag so that strings enclosed in quotes will be read as immutable strings (whatever they are called), because most string constants wouldn't end up as general mutable buffers.