I may be thinking in the wrong direction, but right now `PyType_Type.tp_new` will resolves the `metaclass` from the bases and call:
type = (PyTypeObject *)metatype->tp_alloc(metatype, nslots);
where `metatype` is actually resolved from the metatype of the bases.
In contrast `PyType_FromSpecWithBases` immediately calls:
res = (PyHeapTypeObject*)PyType_GenericAlloc(&PyType_Type, 0);
So I am curious whether `PyType_FromSpecWithBases` should not do the same thing, or as to why it does not? I would also assume that it actually fails to inherit a possible MetaClass completely, but I have not checked that.
That is the first question. The second, more important one, is whether ExtensionMetaClasses are a thing at all? Is it reasonable to explore them, or should I rather give up and use something more like ABCMeta, which stores information in the `HeapType->tp_dict`, plus tag on information to the actual instances as needed? Right now it seems completely fine to me, except that the creation itself is complicated (and a confusing, but its MetaClasses...).
I am exploring this for NumPy. PySIDE is using such things and wrangled it into the limited API  (PySIDE needs to store a QT pointer additionally). When I looked the code, I was fairly sure that this only happened to work because Python allocates a slightly larger space (effectively making it `nslots+1`, or 1 above).
As far as I can see, the only thing that happens if I use such an ExtensionMetaClass is that I have a HeapType with a different tp_basicsize. And I do not see why that should be any different than a normal Python object.