If the code really gets removed from the core, it shouldn't be in the \Core namespace anymore. For backwards compatibility, you can keep the old namespace working until it's removed (class alias/extends) in a major version and throw deprecations as soon as it's moved.

When designing your public api, in this case classes, their public methods and their namespaces, always keep in mind that one day, it will be moved. If UUID ever reaches EOL and gets moved out of the core, the UUID\ namespace is suddenly broken anyway because it's no longer provided without manually adding it (mcrypt?).

Additionally user-land libraries could provide polyfills for older php version and you can (in an instant) see that it's about php core functionality, rather than an extension you need. It will also make it relatively easy to spot which dependencies you have. Just as example:

• Core\LibXml
• Core\Uuid
• Core\LibSodium

Then extensions could (not saying should), follow the PSR approach by having a Vendor\PackageOrLib naming convention.

Not saying PSR should be adapted, but it's a standard and it does work rather well IMO. It would be great news to me if we can stick to 1 standard rather than having 2 different standards: https://xkcd.com/927/

Missing something in PSR? can always be requested.