>> A URN-like scheme (the SRFI process is one) at least solves the
>> problem with namespacing.

Here I have to disagree (and agree with Feeley): it doesn't. It gives
conventions, which are good, but conventions aren't forever.

> With URNs we are back with the problem of a centralized system. Some organization has to assign names and “bless” the libraries as conforming to the standards it has. It also makes installing libraries a necessary step and harder when you want some library that isn’t blessed.

Installing can be automatic if the address of the organization's source
repos is preconfigured in the Scheme implementation's default settings.

> A situation that concerns me is the period of time when a library is being developed and not yet ready to be published on the centralized system.  I view libraries as organisms that evolve over time rather than pristine things that will never change (I view SRFIs as the latter, and not the “usual case” for a library). What if you want other developers to try out your “WIP library” and maybe collaborate with its development? You would need a separate installation process for this case, which is just an added barrier to collaboration.
>
> The solution to the problem you mention is to allow a configurable mapping of library names. This is what the Gambit define-module-alias does:
>
> (define module-alias (github.com/old-account/old-lib-name) (gitlab.com/new-account/new-lib-name))

Agreed. Let's have arbitrary mapping. Then we can all get what we want.

Unix has a uniform filesystem namespace into which you can mount web and
FTP sites if you want to. The set of protocols that can feed entries
into the filesystem is not fixed in advance. Decades after the debut of
Unix, people are writing drivers for mounting new kinds of data sources.

The Scheme library namespace should be the same way.

> So the URI in the library name is fundamentally just a way to identify the library unambiguously. In the great majority of cases the URI also points to the repository where the library source code can be found. [Fun fact: if you move a github repository to a new account and/or repository you can still access this new repository using the old name.]
>
> Aliasing is also useful to give a meaning to certain library name prefixes, for example
>
> (define-module-alias (mylib) (gitlab.com/new-account/new-lib-name x y z))
>
> allows (import (mylib a b c)) that is equivalent to (import (gitlab.com/new-account/new-lib-name x y z a b c)) .

Exactly. Scheme projects should be allowed to make shorthands for their
own convenience. Unix mounts and symlinks show that this works great.

> Library registries could simply be a file that gives a list of these mappings so that high-level names could be mapped to specific repositories. In fact, a “registry” could be a Scheme library that sets up all the mappings. Then it would be as simple as doing (import (scheme.org/libs)) to get those mappings.

Here I agree with Marc N-W that ascertaining the origin of libraries is
a meta-level concern outside the libraries themselves.

A Scheme implementation can ship with good defaults (and different
implementations with different defaults, to allow experimentation in a
complex problem domain!).

Nevertheless, the meta-level concerns can probably be described by an
S-expression, and the next natural step is to download that description
from some trusted address...