Hi. I've been listening to the feedback on this thread, and it's changed my thinking about how to present these libraries for review. I'm going to submit Capy and Corosio together as a single review, even though they are separate libraries. Here's why. Capy is a foundational library. It provides the abstractions (tasks, buffers, stream concepts, executors, the IoAwaitable protocol) but it doesn't do networking by itself. Asking people to evaluate Capy in isolation is like asking them to evaluate the STL's iterator concepts without showing them a single container or algorithm. The concepts are correct, but the value is invisible until you see what gets built with them. I wrote about this general problem recently: https://www.vinniefalco.com/p/the-expertise-gap The short version: you can't value the solution to a problem you've never encountered. Capy solves Boost-grade problems, coroutine frame lifetimes, cancellation propagation through deep call chains, allocation strategies for high-throughput servers. These are real problems, but they're invisible to anyone who hasn't hit them in production. Without Corosio demonstrating the payoff, the endorsement request was asking people to take the library's value on faith. That's not fair to reviewers and it's not a good use of anyone's time. The thread itself proved this. Ion observed that "it's more difficult to see the usefulness of this framework without some concrete uses." Ruben's questions about sans-I/O and Asio interop required detailed Corosio examples to answer properly. Nigel asked about Cobalt versus Capy, and the comparison only makes sense when you can see what Capy enables at the networking layer. Every substantive question on this thread pulled Corosio into the conversation. So: Capy and Corosio, together. Two libraries, one review. They remain physically separate, and the reasons for that separation are architectural. Capy is pure C++20 with zero platform-specific code. Corosio contains four platform backends (IOCP, epoll, kqueue, select). Libraries like Http depend on Capy but not Corosio. Merging them would force every consumer of buffer algorithms to link against platform networking they never touch. I wrote up the full reasoning here: https://www.vinniefalco.com/p/why-capy-is-separate This isn't unprecedented in spirit. Boost.Serialization is already split directory-wise into a core and individual archives. Boost.Range would have benefited from a similar physical split. A foundational library submitted alongside its primary consumer is a natural pairing. Richard Hodges endorsed the request and I'm grateful for that. His experience with Cobalt and production coroutine systems gives that endorsement real weight. Jean-Louis noted the value of the whole chain of libraries, which is exactly the perspective that a joint submission makes possible. I'm updating the endorsement request accordingly. If you believe Boost should provide a coroutine-based I/O foundation and a networking library built on top of it, your endorsement for a joint Capy + Corosio review would be welcome. To put it in even more simple terms: Corosio and Capy together is Asio2. https://github.com/cppalliance/capy https://master.capy.cpp.al/capy/index.html https://github.com/cppalliance/corosio https://master.corosio.cpp.al/corosio/index.html Thanks