This is indeed a big gap for interacting with non-Rust async APIs where you can't dictate memory management strategy. However, within Rust, it rarely comes up.

This is indeed a big gap for interacting with non-Rust async APIs where you can't dictate memory management strategy. However, within Rust, it rarely comes up. Probably because native Rust libraries/interfaces have no choice but design around it. If you really have to finish some work asynchronously on drop, you can spawn another task from your drop function. But most of the time I've found it's not even necessary, because you can restructure the code to separate the "abortable" part from the "must finish" part (e.g. some network protocol serializer must always terminate a message it writes, but generation of the message itself is typically done elsewhere, so you can set it up so that abort of the message-generating future doesn't abort the protocol-framing future).