Design-wise, Emacs is less an editor with an API and more a set of core editing concepts (buffers, strings with properties... etc) embedded into a flexible language. The core concepts have a native implementation that's hard to change, but they're simple and flexible enough that you can put them together to do all kinds of text-editory (or even not-so-text-editory) things.

Everything on top of the core is written in an open style, with Lispy features that make it easy to hook into or modify anything. Adding a small feature to Emacs doesn't feel like calling APIs from an existing application, it feels either like writing my own code with text editor stuff available as a library or, alternatively, like tapping into and fiddling directly with existing code in the system.

This way of seeing Emacs explains both why it's so flexible and why certain things (better performance on long lines, concurrency) are so difficult: you can express a lot using the core concepts and you can easily change other code that's expressed with these concepts, but making fundamental changes to the core itself is far more difficult. Partly it's more difficult because it's an old C codebase pretty separate from the Lisp world but, more importantly, it's difficult because substantial changes to the building blocks will change or break existing code in ways that are hard to control or predict. It's the very flexibility on top of the core that makes the core itself hard to change, since the higher-level Lisp code is using the core concepts in all kinds of ways.

Emacs either doesn't have APIs or everything is an API, depending on how you look at it - since it's source is available at runtime plugins and modules can be first-class citizens performance-wise.

With Vim at least, and I think Emacs as well (although I don't use it), it seems like they have greater focus on providing the embedded scripting language, than deciding what to expose to the user via an API. In Vim's case at least, this seems to have resulted in multiple third party API-like projects (for things like installing plugins, linters, etc). It isn't clear to me the extent to which this is an artifact of the way the editor is structured, or to what extent it is just a result of having had time for these types of third party projects to grow.

There are pros and cons of course -- these weird shims can be troubling from a performance point of view, but on the other hand a plugin environment can grow, reach popularity, and then fall apart, and not take Vim down with them.

The web stack is abysmally slow, so you have to carefully pick the levels at which you offer extensibility. Emacs doesn’t have to worry about a DOM, CSS, etc. There’s just not that much between between grabbing input events, storing a character in a gap buffer, updating a glyph matrix, and painting the screen. And it’s all heavily optimized to be usable over ancient serial links: https://web.mit.edu/~yandros/doc/craft-text-editing/Chapter-.... So even making each of those steps heavily programmable in Elisp—every key press invokes a Lisp function that can be rebound, or adviced-around, still ends up performing reasonably well on a modern machine.

it's less about being exclusive and more about getting feedback on the specific features we are focusing on and building at the moment.

For now, people pairing/collaboratively writing Rust is our focus, and we are pulling people in that fit that criteria!

There are so many ways to do the same thing...in any language. That's just reality.

but Perl have backwards compatibility, developers keep perl1 source code can run on current version.