Okay, here's the latest.
I had started to outfit some of our repos with boilerplate IPM modules to take advantage of the requirements.txt processing. Modeling some of the things mu team and I had seen elsewhere, we put a FileCopy in the module file to copy the contents of the repo's python directory to a subdirectory of lib/python that matched the root package name.
A high-speed team member picked through the custom loader to suss out the behavior and found that once it encountered the subdirectory matching the root package name, the resolution of the modules that are stored in globals never happened.
So, removing the directory restored the default loading behavior and I will caulk it up to my poor understanding of how repo-based modules are supposed to be deployed.
Assuming that we will eventually have file-based .py modules to deploy, what is the best way to keep FooOperation.py from one namespace out of the way of FooOperation.py in another?
As I try to go a little deeper into importlib, it seems that find_spec should be passed a path that "produces strings when iterated" and there is something about the deployment environment that is causing path to be passed as a string in this case. Only happens when using python-augmented (method) COS classes, as far as I can tell.
Social networks
UPDATE: Adhering to PEP8 conventions on naming packages using lower-case letters and underscores nicely sidesteps this issue. So, for namespace with a root package of "MyFirstPackage" would have a lib/python/myfirstpackage folder with any .py files that need to accompany the namespace in it.
The loader failing because the package matched the root namespace is probably still a bug of some sort, but now that I know a little better about naming conventions I can see why this might not have been tested.
Hope this saves some of you norms (like me) some time if you run across it.