I offer a way-out suggestion just for the hell of it:

It is clear that the non-timeliness of destruction only becomes an issue when an item of some kind of scarcity is held by the relevant object.

In your example above, the item in question is a lock on a file, in other cases it is a database handle, in other cases it will be some other resource.

We can solve *part* of the problem (short of refcounting) by registering such contentious resources internally. Thus, rather than closing the filehandle at the right time above, we would instead have the second open say "I wish to register my interest in a file lock on this file" at which point the registry will say "well shit, someone else already has that, lemme check if I should run a gc".

Its not a particularly pretty concept in that it requires much determining of, and registering likely contentious resources, however due to the nature of the parrot design you may find that it fits quite well as a middle-ground solution, preventing close timing issues within the same instance (although obviously distinct processes will not benefit).