Not really. Notice that grandparent said "the situation is even wilder in the closed gardens". It still exists in open source. Rolling back a set of packages to some older state isn't a trivial operation, and rewrites are incredibly expensive no matter who's doing them.
Open source is a prerequisite, but this isn't a solved technical problem. The challenge is to make codebases rewrite friendly. The bottleneck isn't the rewrite itself, it's all the risk due to the regressions that rewrites tend to cause, and all the stress from trying to catch these regressions before a release. I've been working on ways to express more tests than our current (c 1970) unix stack can support. The goal: to be able to certify a release to production just by running its automated tests. No large projects today meet this standard. Once we do I think we'll be in much better shape to undertake dramatic rewrites, and to reuse code between projects/rewrites.
Open source is a prerequisite, but this isn't a solved technical problem. The challenge is to make codebases rewrite friendly. The bottleneck isn't the rewrite itself, it's all the risk due to the regressions that rewrites tend to cause, and all the stress from trying to catch these regressions before a release. I've been working on ways to express more tests than our current (c 1970) unix stack can support. The goal: to be able to certify a release to production just by running its automated tests. No large projects today meet this standard. Once we do I think we'll be in much better shape to undertake dramatic rewrites, and to reuse code between projects/rewrites.
(More info on my project: https://github.com/akkartik/mu)