A couple of reasons: ferrying a variable-size handle list from the server to the client feels awkward
It is easier of course when variable-size server reply can be avoided, but it is used on many occasion in Wine. I guess, the real question is, which is more awkward: use the variable handle list, or implement the whole new wait object and a logic behind it in the server which to the large extent duplicates a universal async's wait_handle rules?
waiting on the multiple handles can be tricky
'NtWaitForMultipleObjects( count, handles, FALSE, TRUE, NULL );' like in the original MR should not probably be used (for one, there is limit on handle count). But what is the problems to wait for each handle one after another?
Anyway, if for some reason that multiple handles are considered a big deal, that could be some event on the server signaled based on those wait_asyncs just handled internally and not introducing new entities related to specifically cancelled asyncs. But so far I honestly don't see how that can be less awkward.
Let me know if you think I should go back to the old way altogether.
Well, it needs much more look for details which I didn't (just e. g., it probably can't first cancel asyncs and then fail with `STATUS_BUFFER_OVERFLOW`, that should be checked first because otherwise asyncs are already canceled and client can't retry; what ensures proper wait_handle lifetime and if 'blocking' checks do not interfere since wait_handle is currently only used for those I think). In the idea I personally think it is much better, yes. Maybe we should ask for @zfigura opinion as she's been doing a lot around those asyncs and reviewing all the patches so far.