I actually do a lot of clean-up management. There are 10k lines of code in this set of modules, and many dozens of objects get created at the beginning (and destroyed at the end) of even a one-liner invocation. But I've always depended -- at bottom -- on the basic reference-counting rules to make sure that object destruction happens in a safe order (and assumed that this should work even during global destruction). Avoiding circular references and other destroy-time problems has always been a big concern: making sure there are no memory leaks in this code was a primary goal from the very beginning of development.

But I would tend to think that you're right about there being some corner-case oddity here. I guess, to re-state the question, what could cause the following sequence of events:

1. during normal operation: $foo->{bar} => Some::Object::Ref=HASH(0x86ed4c0)
2. global destruction begins
3. at some point during global destruction $foo->{bar} = undef happens -- without any statement to that effect being executed, (and Some::Object::Ref=HASH(0x86ed4c0) is still around and accessible by other means).

The debugger shows that no code undefs $::index->{_def}. So, either:

1. The interpreter is allowed to reach in and yank references out from under objects during global destruction. (And perhaps this is what chromatic is saying about throwing reference counting by the board when the interpreter is ready to exit.)
2. The debugger is wrong.
3. Or, I'm an idiot, and there's something quite different going on here that I've managed to miss completely.