For gst-plugins-0.6.3 a new setup was found where each plugin will become its own ebuild. If somebody wants to have mad, oss, vorbis, alsa then he needs to built: media-libs/gst-plugins-0.6.3 media-plugins/gst-plugins-oss-0.6.3 media-plugins/gst-plugins-gnomevfs-0.6.3 media-plugins/gst-plugins-vorbis-0.6.3 media-plugins/gst-plugins-mad-0.6.3 media-plugins/gst-plugins-alsa-0.6.3 (doesn't exist yet) While this kind of setup provides individuality for users it slows down the build process _a lot_. It took me almost four times longer than with the old setup, since for every plugin the _whole_ gst-plugins tarball has to be md5 summed and unpacked to the work directory. But what takes most of this times is the ./configure step which goes through _all_ plugins to create Makefiles. This is a _massive_ amount of useless time consuming repetition. Why wasn't a USE flag approach chosen?
well one of the reasons here you mention yourself unknowingly, the alsa plugin is broken. Now we can make a selective choice on what we want to include and what not. But the real reasoning was explained in a -dev mail not too long ago and very short in the eclass. That it takes more time is a trade-off we know, but it's the one thing or the other. I dunno why you want to discuss this now it has been long implemented and even went stable with little more as an argument than that it takes a relatively long to configure per plug-in (hardly an issue for most people). Discussion is good, but if you were truly interested i had expected feedback at least a while back and something well argued. Oh and why we moved away from the USE flag approach : it had proven to be unusable over time in this case with the enormous amount of plugins and now gstreamer has become more of a mainline lib it became more and more of a bottleneck.