example: virtual/perl-Unicode-Normalize has a stable version 1.250.0-r3 available and an unstable version 1.260.0 currently. I'm using sys-apps/portage-2.3.51-r1 and the unstable perl-5.26.1-r1 was installed with 5.26.2 being the newest stable version. bug: since my package.accept_keywords unlocks the untested version emerge --update @world then tells me I need to upgrade perl to the newest untested version too. expected behaviour: emerge should single out virtual/perl-Unicode-Normalize as the reason why untested perl is pulled into the dependency tree and inform the user that masking that single package would make the system more "stable"! my system has some packages stable and some not, in this case the package likely was available only as unstable when I installed it and therefore got into the respective file. but if I'd let emerge auto-unmask perl and similar stuff I'd end up with more and more untested packages over time. especially users who do not verify the build-list before accepting manually would get a system that degrades in quality over time. my suggestion is that in resolving dependency-conflicts both possibilities should be considered: changes that introduce more unmasked stuff, and changes that remove them. the least I would expect is an actual pointer to how I could make my system use less untested package-versions, or maybe in autounmasking give a choice between 2 changes (or a new command-line option called automask, choosing removal over insertions of lines in package.accept_keywords, where possible). but it would be best if with stable profile selected also emerge tends to suggest choosing stable over untested stuff. it is possible to unmask everything, so a user who didn't do that should not be pushed towards a system where this defacto has happened through blindly trusing autounmask-write...
