[ ] Right. I think the spec sat in a weird state for quite a while. This was before a lot of new processes were put into place at TC39. The spec kind of lingered with people poking at it, nobody had really implemented it yet, nobody was using it in the wild, because this was kind of pre-Babel, so we didn’t have people really experimenting with syntax on a bleeding edge like that… And I think most importantly now there’s a staging process where you kind of go through stage zero, stage one, and at each stage there are some bars around how many implementations there need to be and how much input have they gotten… But there’s a couple specs in what we call ES6 (which is really ES2015) that predate that process, and one of those specs is the ES modules spec. So it got finalized before there were really many implementations out there. There were some big question marks around the loader, for instance. The module loader is another spec in the W3C that is even less worked on.

Anyway, at the time that it got kind of ratified in ES2015, there was a lot of people saying “Oh, well this is gonna be compatible with Node”, because Yehuda had done a bunch of work looking at how Node modules look and work to spec, and how ES modules work, and “Let’s make sure that they have feature parity.”

When Bradley started to really dig into this though (Bradley Meck) and figured out how we might actually implement this support, he started to run into a lot of crazy edge cases and gotchas in how Node’s module system not only works today and loads modules, but also how it can be kind of dynamically shifted, and stuff like that. And we call them edge cases because you don’t find them until you go way down this rabbit hole, but they affect something like 20%-30% of the Node ecosystem, so it’s important that these actually get fixed… And that’s I think where you really got involved, JDD. You started to work on another spec, and looking at changes… I think you can really dig into this here.