Solution:
• Mozilla Sponsored Add-On Migrator/Converter that transpiles to equivalent WebExtension code
• Separate lightweight container hosts with DTrace for Core and Extensions (not sure if that makes sense, can you help?)
In fact a friend of mine pursues his Dr. degree on Model-Driven "API-Transpilation" (that's how I call it, albeit limited to CMSs), such that API-breaks caused by CMS upgrades don't result in high integration costs for add-on migrations. Having a complete model for the CMS allows him to support convert add-ons to other CMS too.
Why all the anger? Because API-Breaks cause friction, are avoidable and are commonly known as the biggest "cost-centers & risk-factors" in the software industry.
Software-Architects should instead try to find a composable architecture that supports the transition, instead of moving migration costs to the developers. That would allow everyone else to move over more easily.
The anger caused by the limitations of WebExtentions, are they in fact unavoidable? HN, you've a collection of the most clever engineers of the World! Can we find a solution to this?
My question to HN: Do you know an example or show-case of any complex software that reached similar goals in a way that is transferable or at least advisable to Mozilla? I am really interested, if there is a way to migrate from old to new platforms without "API hiccups". Moving (avoidable?) architecture-debts to a huge fellowship of developers doesn't sound like the way to go. I hope you know about guidelines that removes such frictions for us HN devs that we can just follow suit.
PS: I'm a n00b, but incrementally recreating kernel-level APIs on user-land, then writing an abstraction layer ontop, then exposing a limited set of it via Java-Script doesn't sound elegant and counter-productive. Why not reuse an existing kernel and create drivers and bridges or DSLs ontop of that?
Happy Monday and thanks for your time! :)