Milestone release vs. rolling release is a red herring. The real problem is the issue of shared libraries and shared dependencies. This is one thing Windows got right--updating one program (usually) doesn't affect other programs on the system. But in Linux, updating one library or program might introduce bugs into all of the programs using it. Hence was born the milestone concept, where we freeze a known stable state of the entire system and use that, because all the interdependent clockwork seems to work ok at that point; and then the rolling release concept, where we acknowledge the need for new software, but update everything, top to bottom, so frequently that breakage is common.

These approaches have the added side effect of making the distro the curator of the galaxy of 3rd-party software running on it. I find this the most surprising thing--why should the OS provider have to spend the energy curating every single well-known program that runs on the OS?

What we really need is a reform in the way dependencies and packages are managed so we can update one aspect of the system (Firefox, Pidgin, etc.) and not drag in new versions of libraries that can introduce bugs in to other parts of the system. Gobo Linux started edging towards this approach but it's sadly no longer maintained.

An approach that combines a stable core--kernel, video/network drivers, etc.--that is thoroughly tested and rarely updated, plus sandboxed apps that update at their own pace and are not curated by the distro maintainer, would be the ideal approach, I think. We could even keep the concept of centrally-sourced packages.

Is this possible given that Ubuntu inherits Debian, or given the general philosophy and practices of OSS? Maybe not. But it'd go a really long way towards assuaging the constant and unforgivable breakage that happens with every new Ubuntu release. (And before someone chimes in with "you're wrong, it works perfectly for me", I have a single anecdotal data point to counter your single anecdotal data point.)