This is a relatively new thing, but a new concern about
AsyncWriteis that, fundamentally, they were designed around
epoll-like interfaces. In these interfaces, you get a callback when data is ready and then you can go and write that data into a buffer.
I don't think that's fair. Completion based APIs are common in systems for multiple decades. Kernels use them internally. DMA transfers and disk IO are completion based. Windows offered completion based APIs via IOCP since Windows NT. libusb uses them, etc.
I brought up the concern of not supporting those during the standardization of Futures - but it felt like most people had simply not been interested in those enough, because the focus for those was "I want to build a fast HTTP server on Linux".
However I still think async/await is widely useful beyond it. The intent is being a zero-cost abstraction over things which previously made use of callbacks, promises and co. As long as we e.g. can't wrap in a zero (or even "lost-cost") fashion around underlying technologies which are completion based - which is everything in the end if we look down at the hardware layer - that goal is not reached.
That said I am not opposed to standardizing some form of the current
AsyncRead/Write APIs. They have their use-cases. And most of all they are easy to understand and implement by hand.