>  > Package managers need to do dependency-chasing anyway in order to
> resolve packages that depend on other packages. It shouldn't be more
> work to do that on a library level as opposed to a package level.
>
> How would versioning come to play? Packages (at least the ones I use --
> maven, npm) tend to have versions as first class construct,
> that are just important for resolution as and the name. But otoh,
> versioning isn't part of the library itself it seems.
> I mean, we don't generally do `(import (foo bar baz v1.2))`

Indeed, the immediate advantage of package-as-collection-of-libraries is
that the versioning conundrum can be left to the package level. I'm not
sure how much of an advantage it is in the long run, though. By avoiding
library versioning we could be trading one set of problems for another.

R6RS has a standard syntax for adding a version number into the library
name:

(import (foo bar baz))            ; no version
(import (foo bar baz (1 2 3)))    ; with version

However, people don't generally use this and R6RS implementations tend
to ignore the version part when looking for a file to load, so the
precedent isn't in our favor.

Gambit has something in the works to download a package (a collection of
libraries) from a particular tag of a git repo. AFAIK the syntax and
semantics are not yet settled, but something will be added to the
library name to indicate the version.