> I’m a little concerned about this approach because it means random third party modules can affect the global environment for your application, without knowing it.  Since the hook installation happens at import time, and just depending on a library that has such a .pth file will install it, the end application will not have control over its global state.
But "affecting the global environment for your application" is exactly 
what is intended here. You want multiple packages to all load their code 
into the same namespaces (aka module objects), thus of course 
potentially affecting/overriding each other's functionality. That's what 
you get when you have plugins -- a badly-written/incompatible plugin can 
and will break your app.

It doesn't have to "just depend on a library that has such a .pth file", 
it's up to the import hook's implementation. I just gave as example the 
simplest solution that requires zero effort on the main package 
maintainer's part.

E.g. you can only allow adding a new submodule by default, or require 
the "parent" package to "allow" insertions into itself, or move 
registration into the parent's configuration file (so the user needs to 
enable the plugin manually), or provide some more granular code 
injection techniques like e.g. event handler lists that certain plugins' 
functions will be added into. All that matters here is that the hook is 
going to automagically assemble the resulting namespaces from parts upon 
import.

Finally, Python applications don't have full control over their global 
state anyway. Any module can monkey-patch or override any other module 
via a variety of means. So, this risk is not something new or unexpected.