I'm currently working on reasync, which is how I discovered this bug, then found it was a very old known issue 
If you're asking specifically whether we need reasync(unsafe), I'm not sure that's possible since reasync is a bit different than rethrows. With rethrows, we use the throwing ABI, and we can call a throwing function from a non-throwing function by ignoring the error result.
With async/reasync the situation is a bit different. There's no efficient way to call an async function with a "fake" async context from a sync function, so reasync will actually be implemented with a combination of inlining and emitting a second "sync-only" entry point for your reasync function.
A reasync(unsafe) function would mean you have a suspension point in the body that the compiler cannot prove is unreachable, so it's not clear how this would fit in with our current implementation strategy for reasync.