One last thought on this bug.  The problem is that after we try to delete garbage, we really can't know much about the state of the objects in the finalizers list.  If any of the objects that are cleared end up causing a finalizer to run, then any of the objects in the finalizers list may be reachable again.  One possibility is to do nothing with the objects in the finalizers list if there was any garbage to delete.  That means objects with finalizers would be harder to get to gc.collect()--for example, you'd need to call gc.collect() twice in a row.  The first time to clear garbage, the second time to handle unreachable objects with finalizers.  Or the GC could run a second time if garbage was cleared and finalizers was non-empty.

A more complicated possibility would be to track some object state about when a finalizer was run.  If any of the objects in finalizers had a finalizer that ran while garbage was cleared, we could skip the finalizers list.  I don't know how to implement this, since an arbitrary C type could run Python code in tp_dealloc without notifying GC.