> I consider Py_tp_bases to be a mistake: it's an extra way of doing things that doesn't add any extra functionality

I think it does add one extra bit of functionality: Py_tp_bases allows the bases to be retrieved with PyType_GetSlot().

This isn't quite as applicable to the metaclass, since that can easily be retrieved with Py_TYPE(type).

> but is sometimes not correct (and it might not be obvious when it's not correct).

Yes I guess that most all slots are ok to share across sub-interpreters.  I can see the argument for aiming to keep slots sub-interpreter-agnostic.

As a tangential point, I think that the DLL case on Windows may be a case where Windows is not compliant with the C standard: https://mail.python.org/archives/list/python-dev@python.org/thread/2WUFTVQA7SLEDEDYSRJ75XFIR3EUTKKO/

Practically speaking this doesn't change anything (extensions that want to be compatible with Windows DLLs will still want to avoid this kind of initialization) but I think the docs may be incorrect on this point when they describe Windows as "strictly standard conforming in this particular behavior."