I realized the following when I wrote an ebuild which "naturally" could need a huge string to decide which submodules to install (app-shells/zsh from the mv overlay, but this example is not crucial): A clean way to implement this in ebuilds is to specify (in this example): USE="[other USE flags] completion_... completion_.... completion_..." and to set USE_EXPAND="COMPLETION". However, logically, this USE_EXPAND should be part of the ebuild, and, logically, it should even be local to the ebuild: If some other package by accident has a flag which starts with "completion_", it is not reasonable that this package is also subject to the USE_EXPAND, just because another package needs such a list. Also when I think about the current main examples of USE_EXPAND (APACHE2_MODULES, ALSA_CARDS, VIDEO_CARDS, etc), it is always the corresponding _ebuilds_ which logically should know that they want USE_EXPAND variables. So setting them profile wide makes not so much sense for these IMHO. There are some exceptions like LINGUAS for which it would not be convenient to specify them in every ebuild, so it makes sense to keep some profile wide USE_EXPAND settings. However, being able to define USE_EXPAND "locally" in a particular package seems like a natural enhancement to me and could be implemented in some future ebuild EAPI without breaking any compatibility with the current behavior.
that variable would need metadata caching again, instead, one could squeeze it into IUSE pretty nicely (see also bug #471776) which also avoids repetition: IUSE="regular_flag language_plugins: php ruby python other_plugins: foo bar baz" metadata.xml: <use> <expand name="other_plugins> <flag name="foo">enable foo</flag> </expand> </use> and to solve bug #133327 one could then write a simple parser to extract IUSE_OTHER_PLUGINS from the IUSE, either in PMS or in an eclass.
