It is worth noting that mixing stable with unstable requires some knowledge and experience to tell the difference between a real bug, and a problem caused by invalid mix. Those "invalid mix" problems could be considered incomplete package dependencies, but in practice the assumption that the system is fully stable or fully ~arch and that all packages are fully updated makes things a bit simpler.
Now I'm going to try to answer the questions from Jeremy's post.
How should Gentoo make it easier to add packages that break reverse dependencies if ~arch isn’t appropriate and nothing really happens when package.mask’d?Well, maybe the "nothing really happens" part is the problem? It requires some effort to build a little community testing various packages, but it really pays off. In case of www-client/chromium and related packages, we have an active, growing community, and many of those people are using hard masked, and even 9999 ebuilds. Okay, poppler is a bit different (it's a library, it's not as "interesting" as a web browser), but have we tried getting more people interested in testing it? I think more people follow the Gentoo Planet than read random package.mask entries.
Is ~arch becoming a second stable tree and thus losing value in general?I'm not using ~arch daily, so I don't really know. However, I consider ~arch not being broken "all the time" a good thing. It has to be useable if we want people using it. It may be worth reading about Debian's experiences with testing.
Related, are overlays hurting Gentoo? The Xfce team subscribes to the theory that ~arch is the place to get useful testing feedback. The Xfce pre releases are in ~arch so the final release is ready for arch asap. This means that we have less work in the long run because we are maintaining less versions sooner and in better quality.Yes, I think overlays, if overused, may be hurting Gentoo, causing unnecessary fragmentation. I'm really glad to hear that XFCE team keeps things in the main tree. I'm using XFCE daily (stable system), and I like the end result of that.
portage-2.2 has this cool “preserved-libs” feature that wouldn’t help compilation issues in this case but might help runtime issues by keeping the old lib(s) around. I like this feature but it is still masked for majority of the users, even though many devs are using it – is it time to release it to the world with all the bugs it has?No idea. I trust Zac's and portage team's judgment.
Related, does masking a feature block contributors? I want to say yes simply due to exposure.I'd say it depends on the contributors and visibility. If it's a random entry in package.mask, don't expect that people will "just" unmask it and start sending bug reports and patches. Similarly, people who can unmask things and are interested in what to unmask, following developers' blogs, etc, are more likely to submit useful bug reports.
Finally, let me quote a very important part of Diego's "Put it there and wait for users to break" isn't a valid QA method:
Simply put, do your own homework: learn about the package you’re maintaining, try hard not to break reverse dependencies; if it happens that you break a package unexpectedly, hey, it’s ~arch, we can deal with it. But do not commit stuff that you know will break a good deal of the packages depending on yours. Especially if you’re not out there to fix them yourself.