It is (almost) always a bug if there is a library listed in NEEDED.ELF.2 which is not explicitly listed in RDEPEND (or in @system): The only exceptions I can think of are packages compiled without -Wl,--as-needed (although one can argue whether packages requiring this shouldn't have a correspondingly enlarged RDEPEND), or binary packages which must get exceptions from such QA checks anyway. Such a check would help to reduce the number of undetected "automagic" dependencies (currently a search for "automagic" yields 74 open bugs, but I guess many are not reported or never detected). At least, it would be nice if there would be a script a developer can run. Implementation-wise, for speed reasons, it might be a good idea to manage a cache of all @system libraries (according to /var/db) (for a separate script, it be enough to have this cache in RAM). Then one just has to add the RDEPEND libraries (according to /var/db) to that cache as a set (hashed, e.g. as a python set) and go through the actually used libraries whether there are misses.
Some kind of dependency resolution for some packages (often virtuals) would be needed. E.g. @system set contains virtual/libc, but not sys-libs/glibc, sys-libs/musl etc., but libc.so belongs to sys-libs/glibc, sys-libs/musl etc. (Special handling based on category should be avoided...)
Depending on USE-flags, the dependency list might become too long. An alternative might be to maintain a hardcoded list of "allowed" @system libraries (either in portage or in the profile): I suppose that the list would not be much more than the various libc+compiler libraries. Such a list would eliminate the most complicated step in the implementation.
The aforementioned situation also affects virtuals not in @system set. E.g. packages which use libudev.so should directly depend on virtual/libudev, not sys-fs/udev, sys-apps/systemd, sys-fs/eudev.
Beside "virtual" category, there is also "java-virtuals" category. It is not impossible that there will be more virtual categories in the future. PROPERTIES="virtual" [1] could be used... [1] https://archives.gentoo.org/gentoo-dev/message/9d449a18a96a25a547fcfd40544085cf
While this hasn't been implemented in Portage itself, app-portage/iwdevtools does handle this. (I started an implementation about a year ago - no idea if I've still got it - but wasn't happy with the complexity being added, given that ideally it'd be on the Bash side like the rest of our QA checks.)
*** Bug 234269 has been marked as a duplicate of this bug. ***
