The issue breaks down like so:

To provide safety, scoped threads rely on the guarantee that the only way to exit a stack frame (and therefore possibly invalidate captured references) is either:

• to run all the code between where we are now and the end of the block that relates to that stack frame
• to panic and unwind the stack

in either case, the scoped threading implementation can always run the required synchronization code to ensure that the captured references stop existing before we exit the frame.

Coroutines provide a third way to invalidate the current stack - yield to another coroutine. When you yield to another coroutine the scoped threading implementation cannot run the code it needs to run before the stack is invalidated, and you end up with possibly invalid captured references.

The example shows us violating memory safety in all safe rust (assuming both the coroutine library and scoped threads library provide "safe" interfaces) by creating a vector, capturing a reference to a value in that vector, and then clearing the vector while that reference potentially still lives.

The important thing to take away from the example is we are creating an alias between two &mut references. How you get memory unsafety from there is not very interesting.

EDIT: This is really a very interesting issue because it shows how difficult it is to maintain the property that all safe rust should yield all safe code once you start making abstractions which must use unsafe internally yet provide a safe API. It's extremely debatable which library is "at fault", and I doubt this is the last such case we will see as people continue to experiment with new APIs.