Please consider having two separate SRFIs:

    one SRFI uses strings, corresponds to current practice,
    and is likely to become widely implemented and accepted

    the other SRFI uses bytevectors, does not correspond to
    current practice, is likely to be implemented only by
    some fraction of the minority of systems that implement
    either SRFI 4 or the R6RS, and is likely to be used only
    by programmers who use those systems

This is a case where solving 99.999% of the problem with a
solution that uses a data structure supported by 100% of
the leading implementations is likely to be better than
trying to solve 100% of the problem by using two different
data structures, each of which is supported by at most
25% of the leading implementations.

Abdulaziz Ghuloum asked:
> As for R6RS bytevectors vs. SRFI-4 u8-vectors issue, well, you
> can define this filter procedure to take either a bytevector or
> a u8-vector and it won't matter much in practice: no system is
> going to support both R6RS bytevectors and SRFI-4 u8-vectors at
> the same time (right?)...

Wrong.  Users of both PLT Scheme and Larceny are already
writing significant programs that combine R5RS SRFIs with
ERR5RS/R6RS libraries, and that kind of interoperability
will only become more important as ERR5RS/R6RS libraries
grow in popularity.

> ...and if you write a program using this
> SRFI, you're going to either write it for an R6RS implementation
> (in which case you'd be using a bytevector and your library will
> be okay in all R6RS implementations that support this SRFI), or
> you will write your code for an R5RS implementation (in which
> case you'll use whatever byte array representation that your
> implementation provides).

Users of PLT Scheme are already having to marshall their
lists when passing them from PLT-native code to R5RS or
R6RS code, or in the opposite direction.  Please don't
inflict that kind of marshalling on everyone who uses
getenv in an R5RS/R6RS-capable system.

Shiro Kawait wrote:
> Ultimately, the choice depends on the purpose of this srfi.
> If this one just wants to summarize "current practices", leave
> the behavior undefined and cross your fingers that it works
> "most of the time".  If this one wants to provide a portable
> and robust basis, specify the behavior and encourage existing
> implementations to follow.  I tend to vote the latter.

If you want portable and robust behavior, then you should
try to avoid data structures (such as bytevectors) that
are not even implemented by a lot of systems, and have
competing lexical syntax and semantics (SRFI 4 vs R6RS)
even when implemented.

Will