Isn’t this exactly the same issue that scoped thread spawning used to have?
In that API, the problem is that a thread could continue running and still access data outside its lifetime, while here it’s that an I/O request running in parallel (in hardware or in the OS) could do the same.
Even if you add AsyncDrop, there is no way to guarantee that it will be called instead of having the future forgotten, so it’s memory-unsafe.
The only fix I see is the same as the scoped thread spawing problem, i.e. providing an async function that takes a closure giving a “I/O scope” that lets you create completion-based futures.