@wildwiz, those were just trivial examples to prove that mistakes happen. Here, look at /lib64 for library dependencies that also cross the boarder.
Code:
./libgcrypt.so.11.6.0
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007f4206fe1000)
./libgudev-1.0.so.0.1.0
libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f8cbeaf6000)
libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007f8cbe8f2000)
libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f8cbe3bd000)
./libcryptsetup.so.1.1.0
libdevmapper.so.1.02 => /usr/lib64/libdevmapper.so.1.02 (0x00007fe043e6a000)
libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x00007fe043bf2000)
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007fe0439ef000)
./libnss_wins.so.2
libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007f772da8f000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f772d880000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00007f772ce2b000)
libwbclient.so.0 => /usr/lib64/libwbclient.so.0 (0x00007f772cc0a000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f772c9f1000)
libssl.so.0 => /usr/lib64/libssl.so.0 (0x00007f772c79e000)
libcrypto.so.0 => /usr/lib64/libcrypto.so.0 (0x00007f772c414000)
However, you're right. All this stuff can be fixed without implementing a merge and I said as much above. That wasn't really my point.
IMO the biggest issue with this 'merge' proposal is that the advantages it brings are only trivial and might not be considered worth the cost of transition. That aside, I still think the idea itself is sound.
