I'm trying to find out the common cases where dead-on timely destruction of objects is necessary, such that the lack of timely destruction would alter the semantics of the program badly enough to break it.
I ran into cases where delayed destruction caused problem while working on database drivers for Smalltalk years ago. There may be a parallel to Perl. These drivers were the equivalent of DBD. Instances of drivers would hold external references to stuff in the native database libraries. If one dropped a reference to a database statement, ideally what would happen is that a destructor method would make the necessary call to the native database library to free the statement. (We were using "weak reference" under the covers to make this work.) But ParcPlace Smalltalk would only destroy objects after a garbage collection sweep, which could be deferred in time. We ended up having to manually trigger GCs at points to force "finalization" of database driver objects.
The parallel that might hold for Perl is where an object "holds" an reference to an object in an external system (e.g., a database statement handle), and where having the external object "open" is semantically different from having it closed/freed. If script drops all references to the Perl-side object representing a statement handle, but the invocation of DESTROY is delayed, the external system (the native database library) could be left in an undesirable state.
