Derick Eddington wrote:
> ---------------------------
> Changes I'm undecided about
> ---------------------------
>
> 1) [...] instead of (foo) use (foo main)

Please don't. If I develop (foo) in a separate directory, I do not want
it to suddenly become (foo main). This would be syntactic clutter I
would not forgive as an end user.

> 2) [...] (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" [...]

URI encoding gives a well known precedent, no need to break it.

> -------------------------------------
> Changes I assume aren't controversial
> -------------------------------------
> [...]
> 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.

You need the element separator to extract the path list, so it should be
defined. Path separator on the other hand is something you don't care
about beyond constructing sub-paths -- a process invisible to the user,
so you don't need to define them beyond "recognizable by the OS".

> 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.

I heard that when you strive to fail safety it's best to enumerate
allowed things, not the forbidden ones. How about "Encode everything
except for [a-zA-Z0-9_.-]"? It's safe, short, simple and works for 99%
of libraries without any encoding at all.