A half-baked thought has been sloshing around in my head. Perhaps I can bake it some more by writing it up.
Reference-counting and finalizers that can fail are uneasy partners. When managing lifetimes manually, you control where finalization happens. When finalization can fail, you're as empowered as you could be to make it fail in a place where you can handle the failure sensibly. Manual resource management is tedious and error prone, and that's a serious problem. Garbage collection takes it off your hands. Good. But now finalization happens at some future time, and in garbage collection context. Fine when finalization's side effects are sufficiently harmless. But what if finalization can fail? We trade one serious problem (manual resource management) for another one (handling finalization failures). Reference counting is slightly different. Here, finalization can only happen at unref, which means you retain more control than with garbage collection. However, we do need unrefs in places where we can't sensibly handle failure. For instance, when code operates on an object whose reference count can be dropped concurrently, we need to guard with a ref/unref bracket to keep the object alive while the code is messing with it. The only way out I can see is to systematically avoid finalizers that can fail, by extracting the part that can fail into a shutdown method, to be called in a suitable context, and before finalization. Yes, this takes us back to manual resource management, only we manage shutdown instead of death. Finalizing something that has not been shut down would be a programming error. A recoverable one, I guess; we can have finalize attempt to shut down then, and if it fails, just weep into the logs and move on. We gain a "shut down" state, and new problems may well come with it.