I think Vinnie eloquently put into words my thoughts as well. When I saw on slack that when someone tried an early version of Async and it immediately segfaulted when trying to do a client SSL handshake, I realized the library has seen exactly zero production usage by any real financial stakeholders. I agree with Vinnie's assessment that the library seems hastily written and I'd call it under-tested. Or at least, it was then. Note, I don't call it a coroutine library because it doesn't contain any primitives one would use to write a runtime. Instead, it _is_ a runtime which is something different altogether. Even worse, it's an opinionated runtime favoring I/O workloads and it brings conditional dependencies on Container which I feel ultimately harms it. I haven't formalized my rejection but in similar thoughts as Vinnie's, I'm not opposed to acceptance because I'd be curious if it gains any real users by being included in Boost and who knows, maybe people will actually like it. Note, I've shipped applications written in Asio and I'm also the author of my own coroutine I/O runtime built on top of io_uring so I know both domains well. I don't see much of an onus to ever use Async over Asio but clearly other Asio users do so I'd be curious to see how this library fares. - Christian