(Replying nowhere in particular) This is indeed a bug, but not the ones that have been suggested. The underlying problem is that the DJB programs (mail-mta/netqmail, but also net-dns/djbdns, for example) require a particular service manager. When OpenRC is installed only as a side effect of being listed first in virtual/service-manager, it becomes "redundant" after one of the DJB programs pulls in daemontools, and portage will offer to remove OpenRC.
That's not really a problem with @system or virtual/service-manager. On a distribution where users are supposed to be able to choose their init systems, a package that requires one specific init system is just a bad fit -- for exactly this reason. So in my view, it's a bug in djbdns/qmail. We should have made them support OpenRC and systemd. I am halfway responsible for this, since I maintain djbdns and have never figured out a way to make it work with OpenRC (which would prevent it from pulling in daemontools, which would prevent --depclean from trying to remove OpenRC). But, as the maintainer of djbdns, I can let you in on a secret: don't use djbdns. And if you're not already heavily invested in qmail, postfix is better in every way. There's no upstream for these packages so you're unlikely to see any of this fixed, especially when there are better alternatives. With all of that said, maybe in the Handbook we should tell OpenRC users to "emerge openrc", in case some other not-mutually-exclusive init system is ever pulled in by another program.
