<div dir="ltr"><div>I am hesitant to call this "maximally minimal" because the driving force behind coming up with this varies significantly from what drove maximally minimal classes. The driving force for this is the realization that the module system is perceived as being not close enough to being finished for ES6, yet is agreed to probably be the most important feature that could end up in ES6.<br>
</div><div><br></div><div>The goal here is not to claim that all is lost with the module system in full, because I do think that's not a certainty yet. I do think it is a likely enough outcome that there should be a fallback to capture the most important parts and make sure that they do make it to ES6. I think these parts can be limited to a subset of the module system that is agreed upon and is the most important parts of it, without compromising any other the other "at risk" parts for the future.</div>
<div><br></div><div>The premise of my concept for a minimal foundation system rests on the following assumptions:</div><div>* The import syntax that parallels with destructuring is favored and mostly agreed upon.</div><div>
* The _most_ important part of the module system needed for ES6 is the ability to import internal modules ('@iter'...).</div><div>* The points of contention about the current module system are mostly about exporting user modules (resolving, etc.).</div>
<div>* Internal modules have no need for resolution/export specification, only import. Nor do they need any specification for special binding, since they will be immutable.</div><div><br></div><div>The proposal extends simply enough from those assumptions: Pieces of the module system specification that are needed to support loading internal modules should be prioritized over all else, and the expectation should be that this will definitely work in ES6:</div>
<div><br></div><div>    import { Symbol } from '@symbol';</div></div>