Let's say I write a generator coroutine that gives the letters of the
alphabet up until z, and then co_return's.

So let's say we invoke the routine and get a generator object from it:

        auto gen = GetAlphabet();

Next let's say that we invoke the generator 5 times giving us a,b,c,d,e.
But then, before the coroutine has co_return'ed, we destroy the generator
object. I haven't been able to find out from websearching what's supposed
to happen if you prematurely destroy the generator object. Is it undefined
behaviour?

Anyway I propose that we can mark a coroutine with [[co_clean]], and that
it will have the following effect:
If you prematurely destroy the generator object, it will behave as though
you invoked the generator again but immediately encountered a 'co_return',
thus all the appropriate destructors will be called for local objects
inside the coroutine.

This feature would be really useful for me in a networking program I'm
currently writing. I have a thread that has a loop iterating through 6
generator objects calling them all in sequence. But when the thread's
stop_token is triggered, it would be convenient to just return from the
thread without having to gracefully end the coroutines.

As far as I'm aware, and I'm open to correction here, at the time of
writing, with C++23, to get this kind of behaviour, you need to follow
every co_yield with a co_return, something like:

    for ( char c = 'a'; c <= 'z'; ++c )
    {
        co_yield c;
        if ( global_boolean_to_stop ) co_return;
    }

And so then in the thread that invokes the coroutines, when the stop_token
is triggered, you need to set 'global_boolean_to_stop' and invoke the
generator one more time. It would be easier instead just to mark it
[[co_clean]].

But of course this new feature proposal of mine won't be viable if the
desired behaviour is already what happens when you prematurely destroy a
generator.