This reasoning is specious for two reasons.
The first, which should be obvious from the fact that people complain all the time about the software they use every day, is that it’s ludicrous to assert that a user wouldn’t use a particular piece of software unless they’re “fine” with it. They use it because it’s the best option available given the circumstances. I could talk your ear off all day about the various pieces of software I use that I’m not “fine” with but either there are no alternatives or all the alternatives are worse.
And the second reason your argument is specious is because even things that are fine can sometimes be better. Fine doesn’t mean perfect.
it’s not the XUL to WebExt transition again, it’s the same transition, just still in progress. As I said above, it’s objective fact that Thunderbird’s code base is linked to Firefox’s and when Firefox makes a big architectural change Thunderbird has no choice but to tag along, because separating that dependency would involve either (a) the Thunderbird team forking Firefox and taking on the burden of maintaining a divergent copy of the entire Firefox tree, which they don’t have nearly the resources to do, or (b) the Thunderbird team completely rewriting Thunderbird which again, they don’t have nearly the resources to do.
The transition of Firefox from XUL, and by extension the same transition in Thunderbird, benefits end users because it’s more secure, it enables add-ons to be be developed more quickly and to maintain compatibility better between releases (yes, this is true despite your complains here; there is some turbulence during the transition but as the turbulence settles down add-ons will absolutely be more portable between releases), and it enables add-ons developers to share almost all of their code between Firefox and Chrome-based browsers and any other browsers that support the WebExtension framework, making add-ons available to more people on more browsers and making it easier for users to switch between browsers without losing the add-ons they like.
If you don’t believe me that these changes make add-ons more portable between app releases, just take a look at how many Firefox or Chrome add-ons suddenly stop working when a new version of Firefox or Chrome is released. The answer is almost none of them, and the reason for that is because unlike Thunderbird add-ons, Firefox and Chrome add-ons aren’t allowed to use experiments, they’re only allowed to use supported add-on APIs, and the Firefox and Chrome teams ensure that those APIs remain stable between releases. That’s the goal that the Thunderbird team is working toward, and it’s taking them longer because they are much smaller than the team that works on either Firefox or Chrome.
Continued development of applications once they’re “fine” is also good for users, because computers and how we use them are not static, and as computers and how we use them evolves the software that we use on them also needs to evolve. Or would you rather be reading your email on a VT100?
If the Thunderbird team had infinite resources and if they weren’t time-boxed by the pace of Firefox changes then they would have had the luxury of building all necessary add-on APIs before releasing new Thunderbird versions. Unfortunately, however, they only have a few people and they have no choice but to release in lockstep with Firefox.
Because of that, during this transition period some add-ons get broken on Thunderbird upgrades. The Thunderbird team is well aware of which add-on functionality currently can’t be implemented in TB115, and they’re working on building the necessary APIs to restore it. Once those APIs are built, the add-ons that use them will be stable and much more likely to remain compatible between Thunderbird releases.
