So module unification was more about changing the file system layout for your Ember source code within a project. That isn’t actually being implemented as originally planned.
AFAIK Ember’s modules started to solidify before the broader JS community and so it was “custom” and there are currently some differences (meaning it does not currently use either standard system). However I think one of the big efforts this year will be to realign the module and build system with the greater JS ecosystem and fix some inconsistencies.
The Embroider project is the new build system and I believe that one of the goals is to first establish a more standard module system for Ember addons to use, transpile from old to new, and then start to deprecate the old module/project setup in favor of the new one.
Currently you can use arbitrary JS modules but you have to use ember-auto-import to import them properly. With Embroider that will no longer be necessary.
Anyway I’m just sort of rambling here and someone more knowledgeable about this stuff like @ef4 could probably give you a much better answer.
Ember has been using ES2015 modules as an authoring format for a long time, and the vast majority of code in the Ember ecosystem is spec-compliant ES2015 modules.
But the ES2015 spec doesn’t actually have an opinion about how module names map to modules, and Ember’s implementation of that has been idiosyncratic and generally only runtime-knowable (as opposed to build-time knowable).
Here’s a talk I did about this area at EmberCamp Chicago: