I found a way to use metaclasses with the limited API.

I found that I can access PyType_Type.tp_new by creating a heap type derived from PyType_Type:

  static PyType_Slot dummy_slots[] = {
    {0, NULL}
  };

  static PyType_Spec dummy_spec = {
      "module.DummyClass", 0, 0, Py_TPFLAGS_DEFAULT, dummy_slots,
  };

  PyObject *bases = Py_BuildValue("(O)", &PyType_Type);
  PyObject *type = PyType_FromSpecWithBases(&dummy_spec, bases);
  Py_DECREF(bases);

  type_new = PyType_GetSlot((PyTypeObject*)type, Py_tp_new);
  Py_DECREF(type);

  #ifndef Py_LIMITED_API
    assert(type_new == PyType_Type.tp_new);
  #endif

  // Creates a type using a metaclass.
  PyObject *uses_metaclass = type_new(metaclass, args, NULL);

PyType_GetSlot() can't be used on PyType_Type directly, since it is not a heap type.  But a heap type derived from PyType_Type will inherit tp_new, and we can call PyType_GetSlot() on that.

Once we have PyType_Type.tp_new, we can use it to create a new type using a metaclass. This avoids any of the class-switching tricks I was trying before.  We can also get other slots of PyType_Type like tp_getattro to do the equivalent of super().

The PyType_FromSpecEx() function proposed in this bug would still be a nicer solution to my problem.  Calling type_new() doesn't let you specify object size or slots.  To work around this, I derive from a type I created with PyType_FromSpec(), relying on the fact that the size and slots will be inherited.  This works, but it introduces an extra class into the hierarchy that ideally could be avoided.

But I do have a workaround that appears to work, and avoids the problems associated with setting ob_type directly (like PyPy incompatibility).