> In conclusion, I don't see why considering library names as
> representations of contemporary file names is proper, and I don't see
> why it outweighs the importance of abstract unrestricted library names.

All of what you say follows from your perspective but is uncompelling to
me from my perspective.  So perhaps we just have to agree to disagree.

But in your second-to-last paragraph:

> If you want to override the SRFI to catch such library names, you can
> also map them to a file name without the SRFI's encoding (maybe just the
> "absolute path" first symbol).  Same for ~.

lies a possible compromise I might be able to justify implementing:
require a system to look first for the unencoded version of the
constructed pathname (ignoring search-path prefixes if the pathname is
absolute in the host filesystem) and, if that fails, then for the encoded
version.  For example, say the list of library directories includes "lib1"
and "lib2" and the list of library extensions includes only "sls".  Then
the system looks for (/ foo) first in /foo.sls, then in lib1/%2f%/foo.sls,
then in lib2/%2f%/foo.sls.  It looks for (srfi :1) first in
lib1/srfi/:1.sls, then in lib2/srfi/:1.sls, then in lib1/srfi/%3a%1.sls,
then in lib2/srfi/%3a%1.sls.  This should allow one to name any file that
exists in the filesystem and to specify absolute pathnames for convenience
or security, without inhibiting the sharing of filenames with funny
characters via the %scalar-value% encoding.  Obviously, a system could
choose not to bother trying the unencoded version of the path name if it
is clearly not valid for the underlying filesystem.

Incidentally, is there a reason to chose "r6rs-lib" as the extension for
R6RS libraries rather than the shorter "sls" as recommended in the R6RS
non-normative appendices?  We selected sls because it did not (to our
knowledge) conflict with existing extensions for Scheme source code, so I
assume that's not your reason.  If there is no particular reason why you
chose r6rs-lib, please change it to sls.

Also, Chez Scheme treats a trailing separator character (":" under
Unix-based systems, ";" under Windows) in its variants of SCHEME_LIB_PATH
and SCHEME_LIB_EXTENSIONS as an indication that the system should look in
the system-specific libraries/extensions if the library isn't found in
the user-specified set.  (This mirrors similar behavior for the
LD_LIBRARY_PATH variable used by some Unix dynamic loaders.)  Perhaps SRFI
103 should do the same.  For example, if SCHEME_LIB_PATH is set to
"foo:bar" on a Unix-based system, the system should look in foo and bar
only, but if SCHEME_LIB_PATH is set to "foo:bar:", the system should look
in foo, bar, and any system-specific library directories.  It is useful to
prevent the system from looking in system-specific libraries if you want
to make sure you know exactly where each library is coming from, and it is
useful for user directories to be searched first if you have a library
you want used in preference to one shipped with the implementation.

Kent