Thanks to Marc Feeley and Per Bothner for responding so quickly.
I think that all three interfaces to string ports (SLIB/Kawa/Guile,
MacScheme/Chez/MzScheme/Larceny/..., and Gambit) should be SRFIs,
but should be separate SRFIs.  I thought about submitting the Gambit
interface as an SRFI at the same time I submitted SRFI-6, but decided
to get some feedback on this one before submitting the other, and I was
afraid the SRFI editors might hold both of them up while questioning
the rationale for multiple SRFIs on this topic.

In fact, the main reason I chose to submit SRFI-6 at this time (when
I have a list of about a dozen other SRFIs that I would like to submit)
was that I wanted to point out that it is better to have lots of
little SRFIs, even if some of them are basically variations of one
another, than to merge alternative interfaces into a single large SRFI.

I was aware that SLIB provides CALL-WITH-INPUT-STRING and
CALL-WITH-OUTPUT-STRING, but I have not used Guile or Kawa and did
not realize that they had adopted this interface.  The SLIB interface
is strictly less powerful than the SRFI-6 and Gambit interfaces, so
it is the most portable of the three.  In particular, it is easily
implemented using either the SRFI-6 or the Gambit interface.  As a
simple, useful, and highly portable interface, I think the SLIB
interface is especially deserving of an SRFI.

Although the SRFI-6 and Gambit interfaces are compatible, in the
sense that an implementation can easily support both at the same
time, they are not interchangeable:  Neither interface suffices
to implement the other in a straightforward way.  The SRFI-6
interface does not provide any way to distinguish string ports
from other ports, so a programmer cannot easily redefine
CLOSE-INPUT-PORT to return a string of the unread characters when a
string port is closed.  Similarly the Gambit interface cannot easily
emulate code that calls GET-OUTPUT-STRING more than once on the same
string port without closing the port.  So both SRFI-6 and the Gambit
interface provide a feature that the other interface alone cannot
easily provide.

Most programs do not need either of these features, however.  Most
programs that use string ports can get along just fine with either
the SLIB or the SRFI-6 or the Gambit interface, using SRFI-0 to
determine which one is available.  That is why I want to propose
the SLIB and Gambit interfaces to string ports as separate SRFIs.

I do not want to revise SRFI-6 to add the SLIB and Gambit interfaces
because, in the short term, I would prefer to have three different
SRFIs for string ports, knowing that most major implementations
support one of them, than to have a single SRFI that no system
supports.

In the long run, I would hope that implementations would support
the union of these interfaces.  I would also encourage implementors
to support GET-OUTPUT-STRING-AND-RESET, which returns the string of
characters that have been sent to an output string port since it
was opened or last reset, and also resets the output string port
so it no longer remembers the characters that have been sent to it
so far.  For example, GET-OUTPUT-STRING-AND-RESET makes it easy to
use an output string port as a buffer to connect concurrent threads.
Input-output ports, as Marc described, would make this even easier.

For optimal benefit in both the short and long term, it seems to me
that we should have at least four separate SRFIs for string ports:

    CALL-WITH-INPUT-STRING and CALL-WITH-OUTPUT-STRING
    SRFI-6
    the Gambit interface
    CALL-WITH-INPUT-STRING and CALL-WITH-OUTPUT-STRING plus
        SRFI-6 plus GET-OUTPUT-STRING-AND-RESET plus the behavior
        of CLOSE-INPUT-PORT and CLOSE-OUTPUT-PORT in Gambit plus
        input-output strings as described at the end of Marc
        Feeley's message

I would like to submit the first, third, and fourth of these SRFIs
in a few days, after giving people a little more time to comment on
SRFI-6 so the new SRFIs will benefit from those comments.  (Having
one person submit all four SRFIs might help to establish that these
are alternative interfaces, not competing interfaces.  On the other
hand, I would be grateful if someone else would save me some of the
trouble by submitting one or more of those SRFIs themselves.  If you
plan to do this, please let me know so we won't be duplicating each
other's work.)

Will