If the package resides in a CPAN-like repository, cpan is the package resolver for that repository, and the package name is foobar, you might write (use (cpan foobar /foofoo/bar)) to use the /foofoo/bar module in that package.
A problem I see with this approach is if you move a module from one package to another. All users of that module will then have to adapt their dependency.
Can you give an example of this? You are correct in that all uses have to be updated, but I don't see that as a bad thing. Moving a module to another package ought to have the same effect as renaming a module, in the same way moving a file does.
IMO there has to be some kind of module hierarchy, all other things would be completely unusable if the module system is supposed to be used for a wide variety of applications, where many different libraries are needed and any combination must be supported. And as I see it, having hierarchy implies this "problem".
Am I getting you right?
You also still have a problem with package name conflicts.
No, I don't. In case of a central repository of packages, yes, of course there cannot be more than one package with a given name, but because it's central that's not a problem. When there is no central repository, the problem doesn't exist, because every package specifies its dependencies a configuration file.
For instance, say that there is a port of the Ogre 3d engine to Gambit. It isn't in any central repository. I am writing a game which uses the port. In the game's package I specify |ogre| to be a package resolver for the Ogre package path.
Anywhere in my game's package, I can issue an (use (ogre /whatever))
Of course, this may cause problems when moving a module from one package to another, possibly requiring a rename of package resolvers. But this is relatively easily done automatically, and it probably doesn't happen very often, because in reality most heavily shared code will be in a central repository anyways.
/Per