Given the recent issues with the Plone 6.1.2 release, I would like to know your opinion about this approach to handle the transition towards native namespaces:
The idea is that, until pkg_resources is there, we will have the package installed like it is now and once pkg_resources is removed the package will be installed using PEP 420 native namespaces.
Theoretically this might work, if you only work with source distributions: then setuptools will read your setup.py and install it.
But if you build a binary wheel with a current setuptools and upload it to PyPI, and then install it a year from now with a setuptools version that no longer has pkg_resources, things might break.
When you build a wheel with current setuptools, and unzip the wheel, you have a nspkg.pth file with as contents collective, indicating that collective is a namespace package. IIRC, this file is only needed for pkg_resources style namespaces. The collective directory will not have an __init__.py: binary wheels never contain this file for any style of namespace packages.
When I edit the setup.py and force an ImportError by changing your import line to __import__("xxxxxpkg_resources"), a wheel with different contents is created. It does not have the nspkg.pth file. This is fine, because it uses native namespaces, so this file should not be needed. But there is a collective/__init__.py file. I think the presence of this file will cause pip (or maybe Python in general) to think that this is not a namespace package at all, native or otherwise. The collective package would be regarded as a simple package, and I would expect an error when you tell pip to install two such packages. Or pip may accept it, but lib/python/site-packages/collective would only contain the contents of one package.
It is a bit hard to try our for real, maybe easier to do with some dummy local namespace packages, but I expect problems.