Documenting explicitly what I believe the expected order of module lock acquisition would be in this case:

    Thread A acquires package.subpackage lock
    Thread B blocks on package.subpackage lock
    Thread A acquires package lock
    Thread A releases package lock
    Thread A releases package.subpackage lock
    Thread B acquires & immediately releases package.subpackage lock

Looking at https://hg.python.org/cpython/rev/64f195790a3a#l4.367 (the commit for issue 22557), there's a potentially suspect change in the scope of a "_PyImport_AcquireLock/_PyImport_ReleaseLock" pair inside PyImport_ImportModuleLevelObject

Specifically, I think we may now have a race condition at https://github.com/python/cpython/blob/master/Python/import.c#L1534, where two threads can *both* end up trying to initialize the same module, since we're no longer holding the global import lock around that "mod = PyDict_GetItem(interp->modules, abs_name);" call and the associated state updates where the first thread indicates that it is already initializing that module so the second thread should just wait for it to finish doing so.