As a result of late unreviewed toolchain.eclass commit, gcc < 4.6 has multislot logic always on (even though the flag is masked). As a result, we have two QA issues: 1. USE=multislot became no-op on those packages. This is a minor QA issue and easy to fix by adding the flag conditionally. 2. A number of ebuilds had SLOT changed in-place. This means that the slotted atoms that people had in @world file no longer match any packages.
(0) calling commits made by toolchain peeps to toolchain code "unreviewed" makes no sense (1) is not a QA issue (2) my tests showed portage upgraded SLOTs of already installed packages, so migration isn't an issue. that doesn't help with existing set files, but unless there's a mechanism for addressing that, then oh well, that's life. i doubt this is really worth spending time on.
if anyone has thoughts on the world migration, feel free to post
