Here's my review of P4253R0. First, what I think are some factual errors: - The paper calls P3950 something Leahy "proposes", but, by the paper's own date (post-Brno), it was well past a proposal: SG1 and EWG had cleared it, and CWG approved it as a Defect Report for C++29. This has two consequences: the abstract's "three of four adopted or forwarded" is really four (it has at least been forwarded), and the third falsification test is arguably already met (see below). - The execute snippet has `<typename F>` but the body uses `T`, so it would not compile. - "Five members" in par. 5 is wrong. `operation_state_base` has seven data members; the paper's own code block shows six; and it says `callback_` is "stored separately" but it is a member of the same struct, instead. The four questions: 1. Fair to Leahy? Yes. I just found one overstatement: Leahy wrote (PR #1501 comment, verbatim): "As a possible quality of life improvement `use_sender` should perhaps identify asynchronous operations which complete with `boost::system::error_code` as the first parameter to the completion handler and coalesce truthy completions to `set_error`, but perhaps that's best left as a separate algorithm to ensure that 'partial success' has its context fully preserved." This seems Leahy thinking out loud (note his "should perhaps" and "perhaps that's best left") but the paper (par. 6.1) says Leahy "prescribed" this. 2. Is the shared-boundary claim convincing? IIUC, this seems the weakest part. The whole argument rests on the word "boundary", yet the paper never defines what "the boundary where the sender model meets I/O" actually is. And the six observations do not share one cause: removing `split` is about a general compute-style algorithm, the `when_all` fix is about structured concurrency, and the `return_void` change is a general coroutine-promise defect the committee is fixing for all promise types; none of these seems specific to I/O. A real common thread does exist, but it is narrower and is a property of the model rather than of I/O: the sender model ends the operation state's life at the completion signal and routes results through fixed, typed channels, so there is nowhere to keep state or data that does not fit a channel - which is what genuinely unites observations 1, 3, and the par. 6 byte-count problem (the paper half-sees this in par. 2's "one-directional" operation-state stack). I would either narrow the claim to that property or broaden it to "the model's invariants cost more when the workload does not fit them" (which par. 12 already hints at), and drop the single, undefined I/O boundary. 3. Are the falsification tests right? Mostly, but: - As said above, test 3 (a reason to remove the `return_void` restriction even without `std::execution::task`) is arguably already met, because the committee is fixing it as a general defect for all promise types: CWG approved it as a Defect Report, and SG1 called the motivation "compelling for maintenance of promise types". - The bolded par. 6 claim "no mapping preserves both values" seems too strong: `set_error` can carry one compound value (a struct holding the error code and the byte count), which keeps both without using `set_value`. So the accurate claim seems to be the one par 6.1 already makes: no mapping preserves both *and* keeps the channels clean. 4. Did AI affect my read? Yes. I checked everything checkable :-). -- Gennaro Prota <https://prota.dev>