I'm not sure the problem is so much that anyone _wants_ to support resurrection in __del__, it's just that it can't be prevented.
Well, Java has an answer to that (at least I believe Tim Peters told me so years ago): it allows resurrection, but will only call the finalizer once. IOW if the resurrected object is GC'ed a second time, its finalizer won't be called.
Right, that's a technical trick Java uses. Note that it doesn't stop resurrection: all the resurrection-related pitfalls remain. One good result is that cycles containing objects with finalizers don't stop gc progress forever; some progress can always be made, although it may be as little as reclaiming one object per full gc cycle (ignoring that "full gc cycle" is a fuzzy concept in a runs-in-parallel threaded gc). A bad result is an endless stream of nearly-impenetrable articles encouraging deep fear of Java finalizers ;-); e.g.,
This would require a bit "__del__ already called" on an object, but don't we have a whole word of GC-related flags?
Nope! You're probably thinking of gc_refs. That's a Py_ssize_t today, and is overloaded to hold, at various times, a status enum (which only needs a few bits) or a copy of the object's refcount (which uses all the bits).