The only example I have is ppp-2.4.2 (-r10 is fine) and radiusclient. Because ppp has a bundled copy of radiusclient, they collide on the library files and the /etc/radiusclient config directory. Only the library collisions are detected. This might be by design, since it will take manual intervention by the user to actually mess up those files, but IMHO it is definitely the wrong way to handle it. For one thing, it may not be clear to the user that this collision situation has occured. Second, it's silly: over time, updates to the two colliding packages will continually try to ping-pong between possibly completely different files or sets of files, which is bound to eventually screw somebody up. Note: in my particular example, the configuration files are compatible, but that is just a quirk of this example - the only example I have - and this could have much worse results if it occurred in two packages that actually aren't so closely related but happen to use the same configuration path. E.g. what if someone made a daemon called, oh I dunno, "Network Transmission Plotter" and unwisely used the configuration file /etc/ntp.conf? :P
It is by design and for a good reason. Portage doesn't remove files in config-protected directories when packages are unmerged. This essentially means that `emerge ppp; emerge -C ppp; emerge ppp` will trigger collision-protect without this hack. Hence, changing the behaviour of collision-protect can't happen until the config-protect is cleaned up.
Ahhh...now I understand. Still suboptimal, but I see your problem.
Yeah, unless someone can think of a better way to deal with CONFIG_PROTECT I consider this CANTFIX.
