Putting .dll's next to their .pyd's isn't a general solution, because sometimes you want to be able to use the same .dll's from .pyd's that are in different directories. For example, scipy.spatial.qhull, scipy.optimize._lbfsgb, and scipy.linalg._flinalg are three different extensions in different directories, but they all link against BLAS. And you definitely don't want to include multiple copies of BLAS; the current scipy wheels on Linux are 50 MB, and 40 MB of that is *one* copy of OpenBLAS.

I don't think import hooks are terribly relevant here either. The big problem is how to arrange for the .dlls to be loaded before the .pyds. The obvious hack would be to somehow automatically rewrite the package __init__.py to either mutate PATH or pre-load the .dlls, which is admittedly pretty nasty. But... if you want to install an import hook, then that *also* requires rewriting the package __init__.py to inject the import hook installation code, and then the import hook would just be mutating PATH or pre-loading the .dlls. So adding an import hook to the mix doesn't seem to be buying much.

I guess I can see the argument for @xoviat's original proposal: if lots of packages are going to have weird code injected into their __init__.py just to add the same paths to the DLL search path, then maybe it's simpler all around if this becomes a standard feature of the Python importer. However, even if this were implemented we'd still need to write and maintain the __init__.py injection code for the next ~5 years, so probably the thing to do is to implement the __init__.py approach first and wait to see how it shakes out before considering interpreter changes.