This is my review of P4253R0.
1. Is the characterisation of Leahy's work fair? The paper claims to examine published code, papers, and talks, and to draw conclusions from them. Is Leahy's work represented accurately? Are any observations taken out of context, overstated, or missing a qualification that would change their weight? If you are familiar with any of the source material, please say where the paper gets it right and where it does not.
The comparison between Asio's and Capy's sender bridge in section 5 isn't an argument towards what you try to state. You are comparing two bridges. Capy's bridge is simpler than Asio's. This is an argument against Asio's model, not towards std::execution invariants' fitness for I/O. I'm not convinced by Leahy's own claim on Asio's "abandonment". AFAIK no operation in Asio, or any of the libraries built on top of it, abandon operations as a form of completion. I'd call an operation that does this a bug. Maybe this was a thing before the introduction of per-operation cancellations? The only real case where abandonment could happen is stopping an io_context before it runs out of work. But then capy/corosio would suffer from the same problem, too. Partial success is correctly characterized. The removal of split() is correctly characterized. It doesn't add anything to the "senders' invariants may not be the right ones for I/O" because none of the arguments are related at all with I/O. It adds to the "senders are too complex" or "senders have undergone too many committee changes" arguments though. If that is the intent of the paper, please state it clearly. The when_all fix description is convoluted and should be simplified. Before the paper, when_all checked for cancellations before starting child operations, and hence would unconditionally add set_stopped_t() to the completion signatures, even when no children supported completion. Again, this has nothing to do with I/O, but adds to the other two arguments that I stated before. The language change is well characterized and adds to the paper's arguments.
2. Is the shared-boundary claim convincing? The central argument is that six observations, each independently addressable, share one cause: they sit at the boundary where the sender model meets I/O. Could the six be explained by other causes? Are there observations from Leahy's work (or from others working in the same space) that the paper omits and that would weaken or strengthen the claim?
See above.
3. Are the falsification criteria in Section 11 the right ones? The paper lists four conditions that would discharge the observations. Are those conditions correctly stated? Are there other ways to explain the observations that the paper does not consider?
I find this section as if it was written to help LLM reasoning rather than human consumption. I'll try my best analyzing it, even if I'm not its target audience. "A sender design that achieves zero per-operation allocation under type erasure for byte-oriented I/O, matching the coroutine model's structural property documented in Section 5." You haven't argued anything about allocations under type erasure in this paper, so I find this weird. "A channel mapping that preserves both the error code and the byte count without routing I/O errors through set_value, matching the coroutine model's compound result documented in Section 6." Correct. "A motivation for P3950R0 [7] that does not involve the sender channel model's interaction with coroutine promise types - that is, a reason the language restriction would need to be removed even if std::execution::task did not exist." Correct. "Evidence that split's eagerness, dynamic allocation, and shared ownership served a use case within the sender model's natural domain (i.e. compute dispatch and heterogeneous scheduling) that has no alternative expression via let_value and when_all." Sorry, I got lost here. I don't see the connection.
4. Did the use of AI affect your perception? The papers in this series, and the review programme you are reading this on, were developed with heavy AI assistance, and I am not hiding that. Whether or not you suspect it of this paper, I want to know candidly whether that knowledge changed how you read it. Did it raise or lower your trust? Did you go looking for tells, and did you find any? Did it make you more or less rigorous than you would be with a paper written entirely by hand? I would rather you name this in your review than leave it unsaid.
Asio is constantly misspelled as "AIO". I found this strange and spent some time arguing with Claude whether this was the case, or I was missing something. I finally watched https://www.youtube.com/watch?v=S1FEuyD33yA, where the AI making the transcription constantly does the same mistake. This is grave enough for a reader to stop reading the paper. The paper also contains the words "thereof" and "thereby" multiple times, even outside Leahy's quotes. This is Leahy's style (which I personally find difficult to read). References to code should use commit hashes rather than branch names to be future-proof. Regards, Ruben.