XUL extensions would block most of the Servo work, as an obvious example. You can't rely on the browser internals if those are changing underneath you.
Which "they" did, and are. Some APIs are more amenable to such replacement than others. For example, APIs that allow you to modify any part of the browser UI in an arbitrary way are not so amenable _and_ have the problem of breaking any time the internal structure of the UI changes. Which has, in the past, prevented improvements to the internal structure of the UI...
It's really easy to see only one side of this (the downside of extensions breaking, or the upside of not having your implementation severely constrained by extensions that keep depending on internal details they shouldn't depend on). But there are in fact people who've thought long and hard about both sides of this.
The upsides are just somewhat more diffuse than the downsides: the former apply to all users, while the latter only to those who have extensions that stop working.
I appreciate that your personal tradeoff was different from most, and I know the pain of having an application that was targeting your use cases move away from that. I don't have much to offer other than the goal that Firefox still has to offer extension APIs that are broader than the ones Chrome does. It won't be quite as "yeah, hook into anything you want" as the old extension system, but that was really becoming completely unsustainable and was holding back Firefox not only in things like performance and responsiveness but also web standards: extensions would depend on things working a certain way and changing them to follow the spec would break those extensions...
I find unfortunate to see such trivialization of dev work from outside. They had to deal with years of legacy code piling up, and this was seriously impeding the modernization of Firefox.
They have. It is not finished yet but work is underway.
I also learnes from last(?) discussion about Firefox here on HN that there is even a developer extension that you can install on nightly that will let you create your own extension api.
This is useful 1. if you are a developer that is happy with using nightly and making/copying extensions on top of your own api 2. even more useful as you can sketch out api ideas in js without touching the Firefox C++ codebase.
BTW: Manishearth who is acrive in this discussion often shares knowledge from the inside of Mozilla. If anyone are really interested then reading his comment history might be interesting.
It makes use of the new Containers experiment to provide a similar tab organization mechanism as TabGroups, and presents them in a vertical sidebar which IMO makes for a much saner workflow for heavier tab users. The identity encapsulation that comes by default with Containers might not be what you're looking for in a pure tab management system though, but as Sea Containers shows, some variant of tab grouping can definitely be implemented in WebExtensions.
0. https://bugzilla.mozilla.org/show_bug.cgi?id=1384515#a545216...
For example, a hugely useful feature for me was TabGroups (Panorama) which they removed from the main browser to make it an external add-on, and even that will stop working soon [0]. Similarly, there are add-ons which modify the browser's inbuilt 'Find in page' behavior in Firefox. Looks like even they are not WebExtension compatible.
[0] : https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...