Thus the goal is to prevent free interaction between processes or between addons and native in general (unix philosophy anyone?). Everyone has to suffer just to protect those who click on "yes, install" whenever prompted.
The result are less powerful APIs in the name of security.
Just look at addon signing. Mozilla refuses to add an off switch to that (and thus user control) because they fear that some other processes already running on the user's computer might inject unsigned addons. In my eyes this is a crazy kind of threat model that basically writes off the user's system security as a lost cause and tries to defend FF against that lost cause. It's elevating mozilla's needs over interoperability between applications.
Imagine if awk refused to run unless the parent process is bash, signed by canonical, because they deemed some other shell's argument expansion as potentially confusing to the user or something like that. Crazy, right?
What we want is the ability to modify the whole browser chrome as if it was a website, and the ability to modify every action that happens in the browser.
(For example, for tree style tabs, or a tab bar at the bottom, or stuff like redirecting some keypresses to other processes).
Vivaldi does provide these things. Vivaldi allows users to literally rewrite 100% of the actual browser with simple JS addons.
Mozilla should provide at least what Vivaldi provides.
A transition like this has two halves: adding the new (performant, maintainable, secure) APIs and deprecating the old ones. Comments like the one above jump to the bizarre conclusion that Mozilla will decide to remove of the old APIs but never add the new ones. The closest thing to an explanation for why this would happen is ... uh, something about pocket and hello?