Hiding the effect of concurrent finalization

I've recently come across a rather puzzling problem and I wonder if it
has been discussed before.  Suppose you have got a language which
sports garbage collection, scope-based automatic resource management
(like the WITH- pattern in Common Lisp, or C#'s "using" construct),
and coroutines (user-scheduled threads, also called one-shot
continuations, I believe), but not (explicit) user-defined finalizers.
Unfinished Coroutines are not automatically part of the root set (this
is different from Java threads, for instance.)

The problem I have is what happens if a coroutine object is
garbage-collected, but there are still stack frames on it, including
some which involve automatic resource management.  Presumably, the
associated cleanup code needs to be executed when the coroutine object
becomes unreachable.  But this means that we now have a generic,
user-defined finalizer facility.  And this seems to be unavoidable.

Consequently, I wonder if there are any good ways of hiding the
concurrent nature of finalization.  One idea that comes to my mind is
to run finalizers for objects of a specific type only when new objects
of that type are created.  Are there any better ideas?

(The Scheme approach involving callbacks for entering and exiting the
protected scope does not seem to reflect reality that well; it is not
always possible to gain access to the same resource after releasing
it.  For instance, a file might have been deleted in the meantime.)