A bit more info:  recall that, when deleting a type object (for class B), the previous (list) object's gc_next got overwritten with NULL.  The new info:  its (the list object's) gc_refs also changed from GC_TENTATIVELY_UNREACHABLE to GC_UNTRACKED,  That the object became untracked is wholly consistent with that its gc_next became NULL but not its gc_prev.

I haven't tracked it down all the way to the offending code, but I wonder whether that's worth the bother.  What reason do we have to believe that

            Py_DECREF(op);

CANNOT cause other objects in the `collectable` list to become recognized as trash too?  We're in cyclic trash, and one decref can trigger an arbitrary number of other objects to become trash.

So I'll attach a patch that doesn't assume the Py_DECREF is harmless, by moving `collectable` objects one at a time to a temporary list, and then - at the end - moves all survivors back to `collectable`.  That makes the error go away, but I can't be certain it's address the real problem (since I stopped looking for the code that messed with the list as a side effect of doing a decref on the type object for class B).