In general, if your software supports plugins, you can:
1. Have plugins with ultimate power (meaning that plugins can change everything, no encapsulation)
2. Stable API/ABI (meaning that plugins written for version 1 will work with version 2)
3. A refactorable code base.
You can pick only two out of three.
Traditionally, Firefox chose 1 and 2, and for stuck without multiprocess support for years (causing it to have worse performance and security), and now wants to move to 2 and 3.
Incidentally, I suspect that's _one_ of the reasons Linux doesn't have a stable Kernel ABI - they chose 1 and 3.
There is one plausible solution to this inequality: the Unix philosophy. Small parts, loosely coupled. Individual parts can't be significantly changed or removed, but they can be deprecated and better alternatives added. Because the parts themselves are small, they're less likely to have errors and replacing them is cheap.
Rich Hickey also has a talk on this. And there's also an overlap with CRDTs (basically you have a distributed system unless you can refactor everything atomically).
Firefox tries to minimize breaking API changes, but there have certainly been plenty of them. While avoiding API changes presumably made the switch to multiprocessing more difficult, it didn't stop it; they made the switch. The fundamental problem with extensions and multiprocessing (at least from the perception of someone who wrote FF extensions) is the obvious one: Rather than having everything for all windows in a single thread, now you have them in different processes; communication goes from literally nothing to IPC.
1. Have plugins with ultimate power (meaning that plugins can change everything, no encapsulation) 2. Stable API/ABI (meaning that plugins written for version 1 will work with version 2) 3. A refactorable code base.
You can pick only two out of three.
Traditionally, Firefox chose 1 and 2, and for stuck without multiprocess support for years (causing it to have worse performance and security), and now wants to move to 2 and 3.
Incidentally, I suspect that's _one_ of the reasons Linux doesn't have a stable Kernel ABI - they chose 1 and 3.