GeezerVison

I think you also need to guard the _PyTrash_thread_destroy_chain() below; otherwise destructors for simple types (like PyLongObject) can trigger arbitrary code execution.

That checks seems a bit more difficult to add efficiently.

otherwise destructors for simple types (like PyLongObject) can trigger arbitrary code execution.

Does that matter?
We only care that PyStackRef_CLOSE_SPECIALIZED doesn't escape and that doesn't (at least, shouldn't) call Py_DECREF.

1. PyStackRef_CLOSE_SPECIALIZED calls Py_DECREF in the free threaded build. This is fixable, but requires more changes.
2. obj.attr += 1 wouldn't be atomic in the GIL-enabled build when using a lot of stack (already not atomic in free threaded build).
3. I think there are places in C code where we assume that Py_DECREF() on certain types of objects doesn't escape and won't invalidate borrowed references. One I encountered is:

   cpython/Objects/typeobject.c

   Line 9345 in 46c60e0

   if (key != NULL && PyDict_DelItem(subclasses, key)) {

   where key is a PyLongObject

We can do it reasonably efficiently with a read of tp_flags. Since we are reading tp_dealloc anyway, the latency is likely hidden.

I think you already brought this up in the meeting, but I don't think this should be necessary. Weakrefs won't resurrect an object with refcount of zero, which _PyTrash_thread_deposit_object() ensures.

I'll put the assert back.