> 1) Should the implicit file name support be removed?

Yes.  It complicates the design and the implementation, and it forces
programmers to remember (or look up) and deal with special rules for
mapping library names to file names.  Special cases like this also
complicate program-generating programs.  If there are tools that make it
significantly harder to deal with a foo directory by itself than foo.sls
and foo together, I'm fortunate not to have to deal with them, and if
there are, it's not too much to ask programmers to import (foo main)
instead of (foo).  Programmers might rather do that than deal with
special cases or have to look in twice as many places when they want to
look at a library's source code.

Extra bells and whistles can be useful, but so are simplicity and
regularity.

> 2) Should the character encoding design be changed to encoding of code points
> (instead of UTF-8)?

I don't feel strongly about this, but I agree with you that:

> the terminating character makes it obvious where a character encoding
> ends; it's marginally easier to convert characters to and from code points
> than to and from UTF-8 encodings; and it is more consistent with Scheme's
> syntax for symbols and strings.

I couldn't have put it better myself.

> 3) I'm thinking SRFI 104 should be changed such that it's required to always
> affect library locating, so that there's a portable cross-system interface to
> reconfiguring library locating.

I don't care one way or another, but I wonder how useful it will be in
practice to have such a requirement.  Even if this were intended to
support only R6RS systems, the semantics will not be clear because of the
control implementations have over when and whether libraries are loaded,
visited, and invoked, and in systems that separate phases, there's always
the question about whether setting the parameter in one phase will have
any impact on the loading of libraries in another.

> 6) Define the pathname component separator character to be #\/ on Unixes and #\\
> on Windows.  Define the environment variable element separator character to be
> #\: on Unixes and #\; on Windows.  The current draft is already tied to Unixes
> and Windows.

Most if not all Windows path-manipulation functions permit #\// to be used
as well as #\\, so I would say that either might be used under Windows.

Incidentally, I dislike tying a SRFI, which is a standard of sorts, to a
particular set of operating systems, even if they are the most popular.
It makes the SRFI less general, and from a global perspective, it helps in
a small way to perpetuate the popular operating systems to the detriment
of other, possibly better options.  I would feel better if there were some
mechanism for extending the set of encoded characters as new constraints
are discovered.  This means the correct pathname for a given library name
might change at some point, but only if it is found to be unusable in some
environment.

Kent