To forestall any communication issues, this message is not addressed to the OP directly but to the general forum reader.
First, in our own code base, we have asyncMap and asyncCompactMap because we'd like to await values within the closures given to map and compactMap. If we did not have these, we would have to write some small but annoying boilerplate: create a result array variable (not constant), reserve its capacity and loop over and act on each element. Another time I found myself trying to asynchronously reduce but bumped into the absence of an async overload, so I wrote the boilerplate and refactored it to use variables and loops.
While we do have functions to cover these, I am an idiot. Was I supposed to extend Sequence to do this? Should I use underestimatedCount to reserve the resulting array's capacity or was that a pointless operation? How will this scale over large collections? Should it be inlinable? Is some other dependency going to introduce this and collide with my own implementation? etc.
Second, there was a recent pitch whose implementation is literally repeated/duplicated. Add that to the ton of overloads some other library authors have to provide.
In the absence of overloads and third party, generic functions duplicating logic, developers would be required to use variables instead of constants. Doing this introduces complexity into reasoning about code and limits intuitions about code since, in order to understand the logic in some scope, we now also need to check the variable is not mutated anywhere else within it (I'd guess that kind of check would almost always result in a "no, it's not mutated anywhere else").
So it seems pretty straightforward that there's a need for reasync.
I guess the reason a proposal has not surfaced is because compilers are hard and it would not be a starter task?