noConflict should have nothing to do with AMD.
Ideally, perhaps. But in practice, [https:github.com/jquery/jquery/blob/master/src/exports.js#L23 jQuery butchers the global namespace], even when loaded via AMD.
noConflict is the recommended solution, remember?
Nor should you ever need to undefine a module.
Ideally, perhaps. But in practice, jQuery butchers the AMD scope by defining itself as the named module,
jquery. This greatly increases the chances of collisions in scenarios where 2 AMD modules (loaded on the same page, without knowledge of the other's existence) depend on different versions of jQuery. I don't know if the AMD spec defines how to handle module ID collisions, but it looks like the RequireJS implementation accepts the first module definition and ignores any subsequent attempts to redefine it. It also provides a means of undefining a module, but that's substantially different from
noConflict's behavior (which returns the conflicting variables to their previous owner).
Another problem that could arise from jQuery naming itself
jquery is that a developer could publish an AMD module that uses a customized copy of jQuery. The developer probably wouldn't think to customize the module ID. As a result, an AMD script can essentially hijack the
jquery module ID before the real jquery.js has a chance to claim it. Any AMD modules that depend on
jquery would transparently be given the customized version. This might even be exploited for malicious purposes...?
The real issue here, in my opinion, is that jQuery defines itself as
jquery, and this makes it difficult for developers to create robust, jQuery-dependent AMD apps/widgets that will be embedded in uncontrolled environments. Undefining (or rolling back)
noConflict is one possible solution, but I think a better solution is to make this an anonymous define call. I know jrburke had some reasoning for hard-coding the
jquery module ID, but perhaps that decision deserves another look.
If the jQuery AMD module is anonymous, developers have the option of assigning it a unique module ID and using it privately (e.g., in their widget), without worrying about breaking
jquery-dependent modules that might already exist on the host page.