When it comes to deciding whether not to specify a mode at all or whether to specify it as `{ mode: "" }`, I prefer the former because otherwise we could do the same for comments and all other future missing settings. `undefined` is very unambiguous.

To me, one case is enough to show that languages don't need to have a mode. Still, the case I had in mind when designing this was Jane Developer creating a new mini-language and her own compiler for that, but not feeling like creating a CodeMirror mode also. Or somebody else wanting to use Brackets with a language where there just doesn't happen to be a CodeMirror mode for yet. OR us supporting languages in the future that use a graphical editor (maybe a UI builder, or an image editor), and not CodeMirror, but still have language-like capabilities, like a "compiler" (image optimizer, sprite generator, image splitter, ...) and live-development support. Specifying a mode there would just be awkward, though we could potentially add a different concept for such files and let "language" continue to refer to text files only.

In the case of Jane Developer we might later want to allow somebody else to write an extension that adds a mode to her language. Previously, there was no mode, now a second extension adds one, and only THEN does modeReady speak the truth if it resolves.

But really, modeReady exists because I wanted the caller of defineLanguage to be able to get the language directly (`var language = LanguageManager.defineLanguage(...)`), while still being able to wait for the mode to load if necessary. The alternative would be to make `defineLanguage` always asynchronous, which is starting to seem more appropriate (technically we could return the language if no mode was specified and a promise otherwise, but I think that's too messy). `_setMode` would consequently also become asynchronous, losing its chaining ability. As Jason pointed out elsewhere, we don't do chaining anyway, so it seems that we should just go the asynchronous route. This allows us to get rid of modeReady.

This discussion raises interesting points, though. Once we make language definitions iterative, there is no clear concept anymore of when a language is fully defined. So code interested in a language might need to specify more than just its ID, in addition it might need to specify what aspects of its definition it depends on. We can't just use APP_READY as the cutoff point because extensions may continue to load asynchronously and we have no way for an extension to declare it's really done with loading (yet). Even then, if we make languages configurable, a user might specify a mode at any given point.

And then there's the question of whether we'd want the mode of a language to be changeable after it has been set once. An extension could offer an improved mode for a language that already has one (but which one would win?), or the user might change which mode to use for a language (maybe not directly, but possibly by changing the extension that adds base support for the language).

Some food for thought.