@basic contains virtual/linux-sources, which resolves to sys-kernel/hardened-sources. Two versions are installed, 2.6.25-r8 and -r9. When calculating dependencies, Portage chooses the new version. $ emerge -pq virtual/linux-sources [ebuild R ] sys-kernel/hardened-sources-2.6.25-r9 But it won't remove the old one, even with the complete atom. $ emerge -pq --prune Not unmerging package sys-kernel/hardened-sources-2.6.25-r8 as it is still referenced by the following package sets: basic $ emerge -pqC =sys-kernel/hardened-sources-2.6.25-r8 Not unmerging package sys-kernel/hardened-sources-2.6.25-r8 as it is still referenced by the following package sets: basic If @basic contains sys-kernel/hardened-sources instead of the virtual, portage works as expected. $ emerge -pq --prune sys-kernel/hardened-sources: 2.6.25-r8 none 2.6.25-r9 It also works with the virtual in @world.
This is somewhat difficult to fix given the way that the set protection is currently implemented. It think what we should do is remove the --unmerge set protection as suggested in bug 243020, and rely on --depclean <atom> for this sort of functionality. I can add support in --depclean so that sets nested in the world are represented separately in the graph and in --verbose mode you'll be able to see which set(s) prevented a given package from being removed.
I think we can consider this fixed by the fact that unmerge of packages referenced by sets has been allowed for some time now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=cdb5a4554b9c73c6d4f32d0f20cb4157b77b6e71
