> Do we want advertising for commercial services in library names in Scheme?
I'd leave that up to users. Is there a particular way we can restrict
it? If we have a lib.scheme.org it will hopefully be neat enough that
people will voluntarily want their libraries to have scheme.org instead
of github.com.

More generally, any large-scale distributed namespace is going to end up
with lots of messy names. I don't think there's a general way to avoid
that problem (other than not being popular enough to have mutually
unknown people coining names :)

> To encode a protocol in library names is crazy if you ask me,
> especially because the most popular protocol changes over time as you
> write.

Fully agreed.

> But without the protocol, we don't have URLs anymore.

 From Python 3:

 >>> import urllib.parse
 >>> urllib.parse.urlparse("example.com/foo")
ParseResult(scheme='', netloc='', path='example.com/foo', params='',
query='', fragment='')

So if you give it a URL without a scheme, it returns scheme='' which we
can fill in with the default.

I'm not sure what the RFCs say about such URIs, but that can be remedied
with a specification like "parse as a URI; if invalid, try prepending
https:// and parsing again". It shouldn't be hard to come up with a
practical rule.

> I guess that most R7RS systems will map the library
> `(foo.com/bar/baz)' to the same file system location as `(foo.com bar
> baz)'. To me, this shows some flaws in the approach.
>
> To use the example from above, GitHub may distribute a library
> `(github.com hacker foo)' under this proposal. Mr. Hacker owning a
> GitHub account wants to distribute `(github.com/hacker foo)'. This
> won't work without a clash.

Good point. I'd advocate for standardizing a simple rewriting and
filename mapping engine to work around problems like this (which I
believe will come up no matter what kind of practical naming scheme we
choose).