There seems (to me) to be a lot of complexity around the hierarchy of precedence when mapping modes to languages.  We have this global 'mode -> (list of Languages)' map, and a similar map within each Language, plus a Language.modeAliases array.  And there are several ways of asking for what Language goes with a given mode.

Not sure I have my head wrapped around it all, but with that caveat I have a few suggestions for simplifying things:

It seems like some complexity stems from trying to make the "alias" option as general & flexible as possible, and I think that might be overkill.  The one place we use an alias today is really not a case of two strings that mean the same mode...it's actually two different modes that we want to present in the UI as the same thing: an inner mode ("html") vs. an outer mixed mode ("htmlmixed").  It might actually be bug-prone/confusing to conflate the two concepts too much, and it might also clean up the code somewhat if we can do something specific to inner languages rather than a generic "aliases" mechanism...

* The per-Language map is not used as far as I can tell -- Language._setLanguageForMode() isn't called anywhere.  How about we remove this part of it until we have a strong need for another layer of precedence?
* Rename 'modeAliases' to something like 'modeWhenInner' -- and perhaps make it a singleton instead of an array.  (It's hard to picture a single user-concept "language" having more than one outer _or_ more than one inner mode.  Certainly various different outer languages could use the same _other_ language as an inner mode -- e.g. "htmlmixed" and "php" both use "html" -- but that's not what this "alias" functionality is needed for).
* Simplify the global getLanguageForMode() to just return the first language in the array.  It's not clear to me that there's any benefit to preferring outer-mode languages, or even what it would mean to have a second language that maps to the same inner mode but _not_ the same outer mode.  (And the global _setLanguageForMode() will warn on mode-usage collisions for both outer and inner mappings, which seems appropriate to me since both seem equally like a problem).
* Keep Language.getLanguageForMode() similar to today (preferring self before calling the global function -- although this seems to me like graceful error handling rather than functionality with a real use case).  We'd lose the this._modeMap check due to the first bullet above though, and we could potentially fold usesMode() into this function since no one else would be calling it at this point.
* Or if we keep usesMode() separate, let's rename it for clarity -- htmlmixed "uses" lots of inner modes, but this function only returns true one of them (html).  Really, it's asking if a mode that maps to this exact language -- so perhaps isRepresentedByMode() or something like that...