>> I think this document is either omitting the important details or it simply doesn't address the namespacing problem correctly. Remember when Prototype.js had a document.getElementsByClassName? Fun times when that broke.
Interfering with other modules' exports is not possible. But modifying the properties of arbitrary objects is just as possible as ever. Modules are all about fixing scope, not about locking down objects.
To put it differently, the document is not a module, it's an object. The module system has nothing to do with it.
This is accounted for in the design. The global object is not in the scope chain of Harmony code, but it is still available to Harmony code via a standard binding in the standard library, and the Harmony modules are made available to legacy JS as module instance objects in the global object. So communication is available in both directions.
>> Harmony modules are made available to legacy JS as module instance objects in the global object.
Does this mean a module is visible like this?
That's kinda what already exists... For that matter, any variation of that (e.g. window.modules.jQuery) can be done with the patterns you mentioned at the beginning of the document.
>> The global object is not in the scope chain of Harmony code
Ah, I see. That's certainly a new feature, but what's a use case for that? I find it hard to justify giving up a few fairly common variable names just for knowing that window.i or whatever is not polluted. It kinda feels like just shifting the name collisions around.