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.
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?
Believe it or not, yes. Ultimately, edi-dev will sell a SEF for $60 US if you can show proof of license from X12 (I had a conversation with them after my original post). The internal license we are going to need from X12 will get us access to the XSD for the messages, which should me usable as a means to get the schema into IRIS (so I'm told).