> But, not being able to name libraries with the same freedom as with all
> other symbols (and that freedom is a big thing I love about Scheme) ...

Yes, but even though you can create a string containing any sequence of
characters, you don't necessarily have the freedom to use it as a
pathname.  Should we modify open-file-input-port, etc., so that we do,
somehow?  Scheme's freedom is curtailed once one interacts with things
outside of Scheme.  That's life.

Have you thought about what to do when a library name translates to a file
name or pathname longer than allowed by the underlying file system?  255
seems to be a fairly common limit for a file name, and 1024 and 4096 seem
to be fairly common limits for paths on Unix systems.  These are fairly
generous limits, but symbols don't have any such limits.  (Plus, 255 gets
eaten up faster when a lot of long encodings are used.)  If I have the
freedom to use arbitrary symbols as library name components, shouldn't
that freedom extend to size as well as contents?

Also, I'd like the freedom to use libraries stored in the user's home
directory, like (~ \x2e;myappinit) in ~/.myappinit.sls, assuming the
Scheme system interprets ~ the way a shell does, as some do.  The encoding
of ~ prevents that.  Similarly, I would like the freedom to import from
absolute path names starting with /, e.g., so a set-uid script can
protect itself from exploits involving the setting of the library-path
environment variable.  The encoding of / prevents that.  One freedom leads
to the loss of others.

I support the notion that we not encode any characters but instead leave
it to library authors to choose names that don't conflict with the systems
upon which they intend their libraries to be used.  Programmers can police
the authors who don't initially comply.  Sure, a library named
(srfi s2 and-let-star) might be uglier than (srfi :2 and-let*), but it's
not clearly better to have a file named srfi/%3a%/and-let%2a%.

Kent