I see this is working for a constantly developing project like browsers. But imagine you just stoped to work on your side project for a year. Now you come back and would just like to add a new feature. You start with updating all your libraries and half of them started to introduce API incompatible changes (the author gave you at least 15 minor releases and three month of transition period but you did not pay attention) and you spent the next two days just with catching up on the development side of things. We did not yet look at all those bugs and security holes which were open in all the libs you used for the last year.

I see a similar friction here we also face between distributions and developers and the main issue for friction seems to be the friction about guarantees for stability. And only after that it extents to the friction about getting the latest version shipped to the user (either developer or end user of an application).

In corporate environments they claimed we solve this all by running microservices and we would just version our APIs to guarantee the stability of our interfaces to our fellow developers. I still would like to see this working for extended period of time in the real world.

I don't see how containers or flatpacks will solve it. At some point someone has to touch it again. Be it for bug fixes, security updates, feature development. If hell breaks loose everytime you've to continue stalled development because something wasn't as stable as expected in your ecosystem we've not solved the problem yet. And it's not solved if we install five different versions of a lib with different sets of bugs in parallel.

Debian ships Firefox ESR, which is supported for over a year and has a 12 week overlap with the next ESR release.