I'm going to do another revision.  Listed below is what I'm thinking of
revising.  I hope this will be the final revision.  I need feedback about some
things.

---------------------------
Changes I'm undecided about
---------------------------

1) Should the implicit file name support be removed?  The sole motivation for it
is so that (sub-)collections of files can be distributed and managed as
stand-alone directories which can be moved around or deleted without having to
remember and deal with straggler files outside the directory.  However, having
stand-alone directories can instead be accomplished with an explicit "main" or
some other naming convention (i.e. instead of (foo) use (foo main)).  Also,
removing the implicit file name will remove the exceptional mapping of library
names (--- main), (--- _main), etc.  I personally am (now) neutral about
removing the implicit file name.

2) Should the character encoding design be changed to encoding of code points
(instead of UTF-8)?  This would require a terminating character after each
encoded character, to avoid ambiguity.  E.g. the library name (a%/b c:*d) would
map to the file name "a%25%%2F%b/c%3A%%2A%d.ext", instead of
"a%25%2Fb/c%3A%2Ad.ext" with the current UTF-8 design.  The motivation for this
is: 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 personally am neutral about changing the encoding design.

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.  Currently, SRFI 104 is designed such that it
may or may not affect the locating of library files, and this is because I
thought it good for systems to have the freedom to implement only the more
abstract SRFI 103 and not care about SRFI 104 but SRFI 104 still needs to be
useful (for working with library files) when externally imported on a system
which does not have it affect library locating.  Now I'm thinking it's too
confusing to have some systems' library locating be affected by SRFI 104 and
others' not be, and I can't think of a reason why all systems supporting SRFI
104 shouldn't have it affect their library locating; systems can still support
SRFI 103 only and not SRFI 104; systems supporting an SRFI 104 which affects
their library locating can still have other interfaces to affect library
locating.  I personally would like to make this change.  Does anyone not like
this change?

-------------------------------------
Changes I assume aren't controversial
-------------------------------------

4) Say that what's addressed is only how source files are found.  Rephrase to
clearly allow systems to have complementary mechanisms for using
separately-compiled object files instead of source files.  The current phrasing
might seem to preclude that.  I welcome suggestions for the phrasing.

5) Rephrase to clearly allow systems to ignore SRFI 103's environment variables
if some system-specific mechanisms (e.g. command-line options) are used to
override.  The current phrasing might seem to preclude that.

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.

7) Add #\; to the set of encoded characters, because a directory could be both
in the SCHEME_LIB_PATH sequence and correspond to a library name component.
Such a directory with a name including #\; is unusual but must be supported,
otherwise an unencoded #\; would be misinterpreted in SCHEME_LIB_PATH.

8) Rephrase to say what the set of encoded characters is and then say why
particular characters are encoded.  The current phrasing is not as clear.

9) Use a term other than "search paths" for the sequence of searched
directories, and use a term other than "search path" for an element of the
sequence of searched directories.  I welcome suggestions.

10) Change SRFI 104's `search-paths' (i.e. whatever it's renamed to) element
type from "path" to "string", so that users can portably rely on the elements
being that type and not some other unknown path type.

Any other suggestions about terminological or phraseological improvement are
welcome.

--
: Derick
----------------------------------------------------------------