@jaimergp @rgommers Late to the party, but as it happens there is an effort to actually create a registry of PURLs, supported in part by NLnet NLnet; C/C++ Package Registry with a focus on C/C++ code that would likely mesh up well with this PEP. I think this is going to morph into something a bit more generic than strictly C/C++, to address the problem of identifying packages that are not in a registry, like GNU libc, the GNU GCC libstdc++, OpenSSL, Boost, zlib, and similar.
Eventually (and even more so since CVE.org has merged PURL support in their schema 5.2) there is a need to have PURLs for packages that do not live in a registry, and this is a discussion I entertained specifically with Linux maintainers.
I will read this PEP in details and report, including reviewing PEP 725: Specifying external dependencies in pyproject.toml (round 2) 