Thank you for the suggestion.

 > In order to allow implementations of SRFI 37 to use the POSIX/GNU C
 > library functions and to make the defined command-line interface
 > interoperable, I think it makes a lot of sense to add this restriction
 > to SRFI 37 as well.

The POSIX spec for getopt says, "The implementation may accept other
characters as an extension."

The SRFI says that it "supports creating programs following the
guidelines mentioned above", and it doesn't say that it enforces a
particular set of those guidelines.

The fact is that these guidelines are widely violated. If we restrict
the SRFI, we break existing applications, and invalidate the existing
SRFI implementations.

> This is even more important today than when SRFI 37 was written
> because most Schemes nowadays understand Unicode and thus the
> character concept of Scheme is no longer the single character, short
> option concept of the POSIX interface.

If you are worried about what might count as a "single character" in the
context of Unicode, then the POSIX standard is a bad place to look for
the answer. The POSIX interface was an (imperfect) attempt to unify
practice which existed before Unicode. POSIX is hopeless at this point
in history.

What is your motivation for the change?

If you are implementing a standard version of the POSIX utilities, you
can just make sure your option processors conform to the strict spec.

If you are creating a Scheme implementation which will claim strict
POSIX conformance, then restrict your implementation of the SRFI.

If you are implementing the SRFI in the context of Unicode, you will
have to come up with a specification which avoids parsing difficulties.

In a prior discussion we've already declared that:

* "POSIX, the GNU extensions, and this SRFI are not formally specified
and conflicting implementations do exist."

* "You may import the source code into your program to avoid portability
issues."

I don't think I can recommend this change. I see where it would cause
harm, but I don't see where it would add value. An application can
already choose to conform to the short option character set restrictions
when it defines its option processors. How would we justify breaking
SRFI implementations and application interfaces?

Thanks again.

--
Anthony Carrico