So there's a vote deadline approaching soon, and before I consider changing my vote, I'd like to better understand what this option entails.

I think the core ideas here are:

   - that literals and the result of symbol->string are istrings with O(1) string-ref,  possibly some cool sharing features, and possibly an exception raised when any mutating operation is attempted.

   - istrings and mutable strings are both strings.    All procedures that operate on strings accept both kinds of strings.

   - the document mentions SRFI-118 is included -- so I infer this to mean that all mutable strings support extension with string-append! and arbitrary resizing with string-replace!.

   - that many (virtually all) of the interesting string-producing procedures from R7RS (scheme base) and (SRFI 13) are re-defined and re-exported here to return istrings.

This is the gist of it, right?    A vote for (SRFI 140) is one that rocks the boat a bit (for the better), while (SRFI 135) is the "safe path" to immutable strings, while risking the possibility that it won't catch on because old code doesn't require updating, and I don't have keys on my keyboard for « and ». ;-)

---------------------------

Aside, just more thoughts on this SRFI, 

If the presumed default behavior of string-producing API is now to return istrings, it seems like more effort should be spent detailing all the ways to construct mutable strings, and I can only contemplate a few such procedures:

(make-string len [ fill ])

Since SRFI-118 is implied, then make-string could be permitted to accept 0 arguments, returning a zero-sized mutable/extendable string.  I think make-string should be reserved to construct mutable strings only.   If the desire to create a filled istring is there, consider adding make-istring, or make-filled-istring.

(string-copy string [ start ] [ end ])

...since substring could now be presumed to return an immutable string always, string-copy might as well be reserved to build mutable strings.

SRFI-13 includes substring/shared.   Would you imagine having this, when given a mutable string as an argument, return a mutable string as a result referencing shared storage -- and if so, what would be the effects of an SRFI-118 operation on one of these "entangled" mutable strings?