FYI, the current CI failures are due to existing code. Basically, that code (in _PyImport_FixupExtensionObject()) tries to delete a [currently] global object that was created by a different interpreter than the "current" one. (There may be a few other similarly problematic global objects. I'll have to check.) As to why only some of the jobs are failing: the failure is a check by the debug allocator, which is only used in Py_DEBUG builds.

FWIW, the failure is exactly what we should expect to happen when per-interpreter data breaks isolation. I actually spent a while trying to figure out what I was doing wrong in my branch before realizing that everything was working as it should. 😄

UPDATE: I've opened gh-101758 to address this.

Given what I've determined via gh-101758, I'll probably need to make non-isolated interpreters share the obmalloc state with the main interpreter.

I'm tabling this until we've isolated all non-static objects.

This PR is currently blocked by:

• gh-98608: Stop Treating All Errors from _Py_NewInterpreterFromConfig() as Fatal #102657
• gh-98608: Fix Failure-handling in new_interpreter() #102658
• gh-101659: Avoid Allocation for Shared Exceptions in the _xxsubinterpreters Module #102659
• gh-94673: Isolate the _io module to Each Interpreter #102663
• gh-102660: Handle m_copy Specially for the sys and builtins Modules #102661
• gh-100227: Move the Dict of Interned Strings to PyInterpreterState #102339 (or the fixes to keep it global)

FYI, as with the per-interpreter ref total, I'm probably going to add some code to preserve the per-interpreter allocated blocks when each subinterpreter is destroyed, so any leaks may be handled appropriately when the runtime is finalized. I may also report the per-interpreter count at interpreter finalization. We'll see.