I really don't like the idea of changing the extension as a way to discriminate between CommonJS and ES modules. Extensions don't pertain to a language like Javascript, which aims for maximum flexibility. What's the next step, a new content type for Javascript modules? Like "text/javascript-module"?
I should be able to load a module from a data URI if I really want to.
I still don't see the problem about AST inspection to determine what kind of module it is. Of course, there are modules that aren't meant to run in strict mode. But if we're talking about an external dependency, we have version numbers for that: let's find a way to specify the type of the module (Bower has dealt with this since long ago). Of course, it's the maintainer's duty to keep their code compatible.
If, on the other hand, we're dealing with an in-project module file, well, developer just have to fix their code if they want it to work with the newer syntax. It shouldn't be a hard work if they're used to put "use strict" at the top already.
Another edge case is when a module doesn't include `import` or `export`. In this case, it's a matter of loading the module, using `require` or `import`.
In the end, in times when the line between client and server side is getting thinner I see relying on file extensions as a relic of the past we shouldn't consider anymore.