So this was on purpose. At some point over the past five years I was working on importlib I think I was told I shouldn't support it (or something) as I explicitly remember making the decision to not support __init__.so on purpose. Plus the package specification never suggested anything but __init__.py to be used to begin with, so it isn't a bug as much as a design oversight (as is a large portion of import semantics unfortunately). But I take it Cython has been relying on this for years so that kind of kills treating this as part of import semantics cleanup.

Now to reverse this several things need to happen. First the whole third item in the tuples passed to PathFinder is unneeded (it existed purely to block extension module __init__ files) and thus should be removed where necessary. Second, the tests for extensions (test.test_importlib.extension.test_finder) need to be updated, but that gets messy as there is no __init__.so in the stdlib to test against to verify everything works. Tests could cheat and muck with PathFinder's file cache, but that is definitely not a blackbox test anymore. Don't know how best to deal with this short of an xx/__init__.so module being added to the stdlib.

And just for future reference, Stefan, since this is a direct import issue and not something to do with importlib's API I consider it an Interpreter Core bug.

And I'm glad we cache directory stat results now as changing this will have minuscule overhead compared to adding another stat call per package search without the cache.