>> 1. Adding an internal encoding tag to the Scheme implementation's string
>> type, allowing a program to mix differently-encoded strings. If the
>> environment variable encoding is unknown, a special encoding tag can be
>> reserved to indicate that. This is quite non-ideal to require of all
>> implementations of get-environment-variable.
>
> I have thought along these lines as well, but I see two problems:
>
> (a) A probably minor one: The encoding of an environment variable is
> always unknown because there is conceptually none. It can only be
> guessed.

True. The getters could take an encoding argument, using the current
POSIX locale as a default. If you get a string encoded wrong, something
like Ruby's "foo".force_encoding("utf-8") could fix it. This is all too
complicated to my taste.

> (b) A bigger one: How should procedures like string-append act on
> strings that are of different types? For example, one string may be a
> string produced by utf8->string, another by, say, utf32->string, and
> the third by `get-environment-variable` from a value that doesn't
> encode a Unicode string.

Good question. There probably isn't a good answer.

>> 2. If get-environment-variable is given the variable name as a
>> bytevector instead of a string, return the value as a bytevector as
>> well. Python 3 does this: compare the return value of os.listdir("/bin")
>> and os.listdir(b"/bin").
>
> That's a nice solution (hack?) but it isn't a general solution. It
> doesn't solve the problem for `command-line` or SRFI 170's
> `current-directory`, for example.

Those are covered by the pre-SRFI:
<https://github.com/pre-srfi/process-state-as-bytevectors>

I don't find it to be that much of a hack: if the OS APIs don't know the
encoding, arguably the natural form of the data is closer to bytevectors
than strings. The input and output data types are nicely symmetrical as
well.