See bug 913628 for the discussion wrt rationale in general. I wonder if it might be worth carving out another special-case (like libc) for the C++ standard library provider. This becomes more of a problem on, say, app-alternatives/tar[libarchive,-gnu] systems where a libarchive->icu dependency exists (so C++ enters the picture earlier than otherwise). If we were to do this, we'd need to introduce a virtual/cxx (or virtual/libcxx, although that might confuse people as it might sound like it's referring to LLVM's sys-libs/libcxx which is just one possible provider) and then be a bit smarter about analysis, by checking if libstdc++ or libcxx is referenced in NEEDED before injecting a dependency. I think it's less clear cut about how to do this rather than the libc one, but worth positing...
This matters for the general case of upgrading gcc (or libcxx) before a package which needs it but the "bricking" issue is limited to the app-alternatives kind of situation I mention above as otherwise these tend to get upgraded at the right time without any issues occurring.
If it were libarchive itself, we could do -static-libstdc++ and such, but it's the ICU part which is a problem.
i'm somewhat skeptical of further special-casing.. perhaps we should just inject library deps into the @system set?
