Library dependencies.

absolute.js

// Defined in Framework
// Uses Mootools
define(['./localFile','Milk/core/Class'], function(local, Class) {

... 

});

relative.js

// Defined in `Framework`
// Uses both Mootools and Polyfills
define(['./localFile','../../lib/Milk/core/Class', 'Polyfills/Array/Array.isArray'], function(local, Class) { 

...

});

UserApplication.js

require({
  packages: [ 
    {
       name: 'Poly'
      ,location: '/js/lib/Polyfills/Source'
    }
    {
       name: 'Mootools'
      ,location: '/js/lib/Milk/Source'
    }
    ,{
       name: 'Framework'
       // this framework names Mootools as Milk
       // and Polyfills as Polyfills
      ,location: '/js/lib/Other/Framework' 
    }
    ,{
       name: 'App'
      ,location: '/js/app/'
    }
  ]
  ,callback: function () {
    //.. make shit happen
  }
})

@unscriptable Does the Framework developers dependency naming dictate what the Application developer must name their shared dependencies ?

Here the user defined Mootools as "Mootools" instead of what my framework called it (which was "Milk"). And likewise for Polyfills. Under this senario - is it the users job simply to plumb the right keys/names to their respective directories (maintaining consistant names w/ what the Framework module defined)? Or does the user have the liberty to assign their own names?

To make things more interesting, outside the theoretical Mootools is composed of 4-5 submodules, Base, Request, DOM, Fx etc. So for something like Mootools, the user would need to link all the submodules by the specific ID's that the Mootools Library has defined. Then in addition to Mootools, the user needs to check the other dependencies for the chosen framework (ie Polyfills - and it's potential dependencies).

Is the only real solution that the Framework developer needs to provide a boilerplate packages property(s) for multiple AMD libs?

If one package is calling a dependent package by the name "Milk" and a second package is calling it "MooTools" then the loader (or builder) won't know that they're the same package. I've been considering a new feature for curl.js that would allow you to easily create package aliases.

Also, I've been thinking about implementing CommonJS Package/Mappings/C, which should handle this case. BravoJs/PINF uses Mappings/C already.

The current repositories of MooTools (Milk), have quite generic names, Base, DOM, Fx, Request, Color, JSON...

Therefor I could see some (hypothetical) collisions.

Because these projects, although they are separate packages, should work well together (when they're finished one day). It would be convenient to just download the whole package, tell the loader 'MooTools' stuff is there, and don't bother with the individual packages. The same would apply to dojo packages: dojo/dojox/dijit.

Extending on that idea passing something like 'MooTools' => '../Milk' to the loader config, would know how to resolve MooTools/Request/JSON while internal packages of MooTools would require Request/JSON. Requiring Request/JSON outside the MooTools group of packages, would try to load another file.

What if two dependent packages have a dependency of different versions of a third packages, but both use Request as absolute mapping?

I don't think something like I just described exists in either the Curl, Requirejs or dojo loaders.. right @unscriptable, @jrburke?

This may sound nice, but on the other hand it adds extra complexity, and how realistic is this (dependency hell?), is it a difficult problem, how many different packages will you have in a (big) application and how hard is it to maintain.

It's a complex problem for sure. Devs want to configure their apps and/or frameworks in all sorts of crazy ways. To my knowledge, @cadorn is the only one who's come up with a way to handle all (sane) use cases (via Package/Mappings/C) in BravoJs/PINF, including the ones you've described, @arian. https://github.com/cadorn/pinf