Colleagues, I am requesting a formal review of P4253R0, "Examining Six Observations on std::execution." The paper examines the published work of one practitioner and asks what his observations share. It asks for nothing. Please all read the same revision, so the summary attaches cleanly to a single document: - Paper under review - P4253R0: https://isocpp.org/files/papers/P4253R0.pdf - The practitioner's papers it examines: P3373R2 (operation state lifetimes): https://wg21.link/P3373R2 P3682R0 (remove split): https://wg21.link/P3682R0 P3887R1 (when_all Ronseal): https://wg21.link/P3887R1 P3950R0 (return_value and return_void): https://wg21.link/P3950R0 - The production code it examines: completion_token.hpp in NVIDIA/stdexec: https://github.com/NVIDIA/stdexec/blob/main/include/exec/asio/completion_tok... use_sender.hpp in NVIDIA/stdexec: https://github.com/NVIDIA/stdexec/blob/main/include/exec/asio/use_sender.hpp PR #1501 review comments: https://github.com/NVIDIA/stdexec/pull/1501 - The CppCon talk it draws from: https://www.youtube.com/watch?v=S1FEuyD33yA What the paper argues Robert Leahy has authored production code in NVIDIA's stdexec, four WG21 papers (three adopted or forwarded by the committee), and a detailed specification of AIO-to-sender bridge invariants. The paper traces six observations from Leahy's published work: 1. A bridge requiring a recursive mutex, an intrusive linked list, and abandonment detection, where the coroutine equivalent requires a context structure and a callback. 2. A channel mapping that discards the byte count on the error path because the three-channel model affords no mapping that preserves both the error code and the remaining arguments. 3. A recommendation that partial success should have its context fully preserved, followed by an implementation that cannot preserve it. 4. An algorithm (split) removed for dynamic allocation, shared ownership, and conditional eagerness. 5. An algorithm (when_all) corrected for injecting stopped completions that no child sends. 6. A language change needed by std::execution::task and by no other task type in a decade of coroutine libraries. The paper argues these six observations share one property: they each arise at the boundary where the sender model meets I/O. It does not argue that the sender model is wrong. It asks whether the invariants the model maintains are the right ones for that domain. Reviews here are informational. There is no verdict and no gate, so please do not feel you are voting the paper up or down. Here are some ideas for questions to guide your evaluation, but your review is welcome to, and in fact should, make observations on any aspects of the paper that you deem appropriate. 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. 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? 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? 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. Thanks