That looks sensible. These days it's the rare package that is just a single .so file though... :-)

If it's a rare enough case that the recommendation should be to package it more like a multi-file package then that seems reasonable to me too. PEP-561 does allude to this when it says:

The single-file module should be refactored into a package and indicate that the package supports typing as described above.

It wasn't clear to me if this applied to single .so file projects as well. But a single .so is a single-file module so I suppose it does. I'd be happy with either approach.

To clarify, this multi-file approach would look like the following:

.../site-packages/
    mypackage/
        __init__.py  # Contains `from ._mypackage import *`
        py.typed
        _mypackage.cpython-37m-x86_64-linux-gnu.so
        _mypackage.pyi

I'll add one detail to the package structure. A single-file extension module can contain submodules. (For example, pybind11 and nanobind have helper functions def_submodule to easily create submodules.) So in general, we can have multiple pyi files corresponding to one .so:

.../site-packages/
    mypackage/
        __init__.pyi
        submodule1.pyi
        submodule2/
                __init__.pyi
                nested.pyi
        py.typed
    mypackage.cpython-37m-x86_64-linux-gnu.so