It is not clear what the purpose of the paper is. The paper has section "Abstract" but it doesn't help figure out the purpose. "This paper traces the path from one to the other." -- yes, but why? Why do you feel it is important to communicate this to WG21 via a paper? Section "Disclosure": first two paragraphs indeed disclose something. The last two do not qualify as "disclosure". Section "Diagnosis". The title is confusing. What is being diagnosed? The sequencing of facts leads the reader to believe that the objection "no way to signal failure from execute()" is the reason why WG21 switched from executors to S/R. There is no evidence for this, but this conclusion, even though not stated in plain text, will be imprinted in the reader's head. Section "The Framing" makes a claim that when you adopt the "schedule work" view then no-failure-reporting is a problem, but when you adopt the "schedule continuation" view then no-failure-reporting is not a problem. I expected to find the explanation for why this is the case. I didn't find any. This is a statement (a key statement, apparently) without a supporting evidence/proof. Section "The Coroutine Executor": I may remember this incorrectly, but it looks like the intrusive pointer implementation indeed allows you to schedule the continuation without any resource allocation: it just cannot fail. It is not that you are concealing failures: you just guarantee with the design that there will be no failures. If I am right about this, this should be stressed as the crucial point, addressing the objection in P2464R0. Section "The Symmetry". It is unclear what the table compares and *why*. "The committee rediscovered that continuations need a continuation-framed executor." -- I do not see how what has been written earlier in the paper would lead to this conclusion. The author assumes that the reader is familiar with the term "continuation-framed executor". This assumption is unfounded. Section "The Return" misses a very important observation. the Executor model just didn't allow reporting errors from scheduling continuations. S/R with std::exec::taks on top gives user an option: either the S/R verbose model with scheduling error reporting, or a "nice" interface without the reporting. This is a huge difference. The fact that Mungo had to explain in this thread what the paper does, is an indication that the paper itself didn't do its good job at explaining its purpose. I find something unethical about this "AI-generated paper + human review requests" setup. Traditionally, a review means:

The author made an effort to communicate something that they feel is important, to make sure that the information is accurate and complete, and that it is presented in a way that it will be consumable by the reader. Reviewers are then requested to check if some cracks still exist.

In this AI setup this changes to:

AI just generates some text, indistinguishable at the first glance from reasoning, intention and intellectual honesty. Reviewers are now expected to engage in an effort to put the product to a shape where the paper communicates something they feal important, to make sure that the information is accurate and complete, and that it it presented in a way that it will be consumable by the reader.

The real effort of making sure that a true idea is conveyed cleanly to the readers is moved from the author onto the reviewers. Yet, the author is credited. I cannot be sure that the content is the AI product. I infer this from my impression where: 1. It has section "Abstract" but after reading it I still don't know what this paper is about and for. 2. It has sentences with the shape of logical inferences (there is a premise cause, there is a conclusion clause), but after reading them I do not know what is communicated and why. Regards, &rzej;

I will note up front that networking is not my domain of expertise. First comment is I was immediately confused by the naming of the paper. Seeing "P3352: " first on the page leads me to believe this is P3352 not P4286. Mungo had to clarify this for me before I was able to begin.

1. Is the historical trace accurate?

The historical trace seems to be accurate. I think it is important that to highlight that ASIO and S/R effectively arrived at the same problem having wildly different architecture. It does sound like S/R does have a narrower requirement on infallibility of schedulers, but it does still seemingly exist.

2. Did the use of AI affect your perception?

I think the issues with AI usage are far larger in this paper than in the previous review. The paper under review here is ~5 pages of actual material which is up from ~3 on Friday when I first looked at the paper (the paper under review has been edited without updating the revision number since Mungo's original post). Once again the issue is that the LLM of choice will have huge amounts of context from sitting in the repo where all of these papers are sitting, and presumably stored context from writing the other ones. This is completely missing to the reader. The entire argument of the paper isn't even in the paper, because it's been offloaded into three other papers. Typically references and citations are for optional additional information, not required reading in order to understand the current paper at hand.

3. Is the structural claim sound?

Yes and no. Yes, I would agree that the infallibility of executors/scheduling has become and issue again. I would argue no in that it's ok to change one's opinion when new information is provided. As noted above, S/R has a widely different architecture than ASIO, and the starting assumption was that they would be able to solve this problem (see P1525). It looks like after many years of research and development they've arrived back at a similar problem in a narrower form. I think it's less they rediscovered the problem and more their hypothesis failed, which in research is completely ok.

4. What is missing, and where is the argument weakest?

As above, I think the argument is weakest in that it seems to posit that once an issue has been identified there's no space for additional research. Opinions have changed on what is possible based on new information, and that should be considered normal and acceptable. Matt

Thank you for giving us this opportunity to review this work. As previously discussed, I am: - not a coroutine expert - not a networking expert - but I know how to write papers and pedagogical material Disclosure: I am compensated by the C++ Alliance, which authored this paper. All paragraphs written in this review aim at showcasing pedagogy/structure rather than making technical points. Overall this work is rather impressive and interesting, but the paper's current form dilutes the message to the point where reviewers had to question its usefulness. This is a shame because I believe the message is interesting and important. The work accomplished is impressive and important: it draws on a decade of technical debates to identify a pattern that previous discussions missed, informing future design discussions. The core information being surfaced by this work exists but is diluted across papers, making it likely to be rediscovered multiple times (or not at all) and causing progress in standardization to be more erratic. Making this explicit in a single paper has merit. That being said, in its current shape, the paper asks reviewers and readers to perform not a review, but a meta-analysis, which is not acceptable. That is, to understand and guarantee the paper's claims, one has to read the paper trail: | Document | words | read at 100 wpm | |---|---|---| | P4286R0 under review | ~2,000 | ~20 min | | P4094R1 | ~8,000 | ~80 min | | P4095R1 | ~4,000 | ~40 min | | P4096R1 | ~4,500 | ~45 min | | P3552R3 | ~19,000 | ~190 min | | P3941R4  | ~8,500 | ~85 min | | P4003R3 | ~5,500 | ~55 min | | P0113R0| ~20,000 | ~200 min | | P1525R0 | ~4,000 | ~40 min | | P0443R14 | ~16,000 | ~160 min | | P2464R0 | ~3,500 | ~35 min | | **Total (10 papers)** | **~93,000** | **~15.5 h** | This poses an ethical problem and a strategic problem.  The ethical problem emerges when unpaid reviewers try to review/read this paper: they are likely to skim through or not complete the review. This biases the review process towards paid work and C++ Alliance affiliation. It's better than nothing but the bias is worth understanding and its consequences on the C++ open source communities must be also appreciated (we want community volunteers to jump in such process, not jump out). The strategic problem is the most critical: the purpose of this paper is to get reviewed by a committee that will likely 1) not have the sufficient background to assess the paper's merit based on pre-existing knowledge of the field, and 2) not have the time to build the required knowledge. IMO the solution to these two issues is, as mentioned by previous reviewers, to make the paper self-contained. I hope to present some ideas below on how to achieve this better. ## Abstract  The first place to begin with is, like the previous paper, the abstract. To increase the chances of being read, understood and accepted, any abstract must follow the same pedagogical pattern. Following the structure from the previous review, it could look something like this (again, I'm no expert here, so forgive technical mistakes):

(broadest context) Designs are governed by invariants that often go unstated as principles. When an invariant is left implicit, the question it governs can be answered one way in one place and the opposite way in another, and the contradiction goes unnoticed because there is no stated principle to check either answer against. This paper surfaces one such invariant in C++'s asynchronous execution model. Asynchronous C++ is built on executors: the objects that decide where a suspended computation resumes, whether it should stop, and how its result is delivered. A recurring design question is whether the operation that schedules a resumption should itself be able to report a failure.

(narrowing) The committee has answered this differently at different times. In 2021 it set aside the Networking TS partly because its executors had no way to report such a failure, and stated this as a design deficiency. In 2026, std::execution::task requires (through affine_on, P3941R4) that the scheduler driving it be infallible, stating as a requirement it may not report a failure at all. The same property is, six years apart, a defect and a requirement.

(narrowing to the method) This paper asks whether that is a contradiction or a consequence. It examines the question across three executor designs spanning a decade, using one distinction: whether the thing handed to the executor is a task to run, with the caller still alive and able to act on a failure; or a handle that resumes a caller which has already suspended and is therefore unable to act on one.

(specific contribution, evidence, take-home) We show that the three designs converge on the same shape: a scheduling step that returns no value and reports no failure. The paper argues this follows from the caller's state, not from any one design, concedes where the correspondence is inexact, and draws a forward conclusion: an infallible scheduling step is the correct form for resuming a suspended caller, which bears on how a coroutine-native execution model (P4003R3) should sit alongside std::execution.

1) Disclosure

1) Disclosure

## Abstraction Layering Overall the abstraction layering is a mess. You want papers layered by abstraction level, similar to how a library is structured: present high level concepts first for easy entry, followed by progressive dives into details. You should isolate concepts at the same abstraction level in similar paragraphs, much like organizing details in a namespace within a library. The abstract, introduction, and transition paragraphs between sections MUST document this structure so the reader understands why they need to understand the details. ## ToC The clearest signal for information layering is the table of contents, but currently it reads like the beats of a blog post: 2) The Diagnosis 3) The Framing 4) The Return 5) The Coroutine Executor 6) The Symmetry 7) A Possible Objection 8) The Shape There is no intelligible message in the ToC, and it's degrading both human and automated capacity to extract high-level signals from the paper's body. They do not signal content or progress, they carry rhetorical/political arcs rather than structure: "The Diagnosis" frames the committee as terminally-ill patients, "The Symmetry" and "The Shape" frame the paper as a revelation. Although amusing to me (I get the intention), this may be felt negatively by others, which endangers the paper for no gain. In an automated pipeline for paper analysis, the first thing you will want to do is extract ToCs for mapping context to pages numbers, which is currently pessimized. So in any dimension considered, this is not an efficient way to convey your message. I suggest something like: 2) Background: the error-channel deficiency (P1525R0, P2464R0) 3) Two framings of execute(F&&) 4) The infallibility requirement (P3941R4) 5) The coroutine executor (P4003R3) 6) Comparison: a shared shape across three executors 7) Anticipated objection: incapability versus selective constraint 8) Conclusion: the shape follows from the caller's state ## Introducing and justifying the paper's structure  This ToC will allow you to layer concepts and definitions in a more efficient manner in e.g. an Introduction or Method (keep the abstract, it answers a different problem). You could write something like:

The paper builds its case step by step. It first establishes the premise that the absent error channel was treated as a deficiency (Section 2), then introduces the distinction the whole analysis rests on, between scheduling work and scheduling a continuation (Section 3). With that definition lens in place, it turns to the other half of the apparent contradiction, the 2026 requirement that such schedulers be infallible (Section 4), and adds a third case that reaches the same constraint with no reference to the committee's history, the coroutine executor (Section 5). With three instances in hand, it compares them and draws out their common shape (Section 6), answers the strongest objection to that reading (Section 7), and closes by locating the cause of that shape in the caller's state rather than in any one design (Section 8)

## Make your definitions clear and explicit

Under the work framing ...

Under the continuation framing ...

This is confusing, as it's hard to understand that you are actually defining terms that are quintessential to the paper. I suggest:

The signature void execute(F&& f) admits two interpretations, here termed the **work framing** and the **continuation framing**. The two differ in what the callable `f` denotes and, consequently, in the state of the caller.

Under the work framing, f denotes a unit of work that the executor runs. The caller has delegated that work and continues to execute; it remains live and expects to observe the outcome. The absence of an error channel is then a defect, since a failure has no path back to a caller that is still running.

Under the continuation framing, f denotes a resumption handle: the mechanism by which a caller that has already suspended, or returned, is later resumed. The work is performed elsewhere, typically by the operating system, and the suspended caller is resumed with the result once it is available. The absence of an error channel is then not a defect, since no caller remains to receive one.

Whether the absent channel constitutes a defect or the correct form therefore depends on the framing, and in particular on whether the caller is running or suspended.

After this is stated, you can then feel free to drop particular paper references and quotes and more details, now that the reader has a high-level conceptual net where to land those bits of knowledge. ## The conclusion does not land well

The committee rediscovered that continuations need a continuation-framed executor.  

This is almost circular and fails to provide a clear takeaway for the reader. If anything it weakens the paper's conclusion and diminishes its chances of being understood. Consider instead closing with something that provides value to the reader:

To decide whether a missing error channel is a defect or the correct form, the criterion is the caller's state, not which model of asynchrony is used (sender/receiver, coroutine, completion token): a step that resumes an already-suspended caller rightly has no error channel (in any model where it occurs) because there is no running caller left to receive one. Stating this once, as a model-independent principle, would spare C++ from re-deriving it design by design. Among those models, coroutines are where this is not one option but the default, since every co_await suspends the caller, so a coroutine-native execution vocabulary could be its most natural home. P4003R3 develops one such model.

## Other

This paper asks for nothing.

I am uncomfortable with this line. A paper always asks for something, and in this specific case it asks for something considerable: that the reader adopts a particular framing of the executor history and accepts an interpretation under which an established constraint is recast as correct, and maybe even read your other paper p4003R3. Maybe you meant "This paper does not ask for direct committee action". ## Did AI impact your perception Since I am being asked, I will answer truthfully. I do believe (personal interpretation) that authors have passed the threshold of AI usefulness in the writing process. There is a point where edition must become manual, paragraph by paragraph, sentence by sentence, word by word, in order to reconstruct a knowledge landscape that can be efficiently walked by a human reader. Humans at the end are reading the paper for understanding, so humans must construct this understanding. Correct but incorrectly structured information is not knowledge, to a reader it will be interepreted as noise. Knowledge is what you get when you arrange the information so that another human can absorb it: that rearranging is an act of intuition about what the reader already holds, what they maybe forgot, what they need next, and in what order. This is precisely what AI is poor at. I don't believe the problem of human pedagogy (i.e. making complex and diluted information intuitive and accessible) is solved by more tokens or more tooling. It is solved by a human doing that work. This connects to the ethical point made earlier. When the manual, intuitive reconstruction is not done (or not enough), it does not disappear: it is transferred to the reader and reviewers, who must rebuild the knowledge the paper should have presented. That goes uncredited, and unpaid for those not paid to do it. The issue is not that AI was used. It is that, in its current form, the final human pass that turns aggregated data into something a reader can learn from does not come through, even where it may in fact have been done. That is not only an ethical concern but a strategic one: you want reviewers, readers, and committee members to come away with the intuition that the work was carefully and manually crafted, and the current form does not convey that. ## Overall assessment Impressive underlying work, undercut by a form that asks the reader to reconstruct it from a very large paper trail. I enjoyed understanding the problem but the irony is that the paper did not really help me do so - I had to reconstruct my own understanding (probably off and/or incomplete), which is not the state you want any paper to be in. If made self-contained (with a pedagogical abstract, a descriptive ToC presented in a dedicated paragraph, concepts defined before they are used, and references used to support rather than carry the rationale), this could become a paper a committee can actually act on and that a reader can enjoy reading, and the message deserves that effort. Thank you again for the opportunity, I'm keen to see where it goes. Best wishes, Arnaud Becheler

The lack of goal makes it hard to review in the context of WG21. I keep thinking that a series of blog post would collect more readership. I.E, because it proposes nothing, and aim not at being presented, there is no point in trying to make it easier to present. I will note that the title implies some sort of proposed change, which will confuse people in WG21. There is some fluff here, that does not help neither the reader nor the paper, namely the disclosure section. just replace that by "This is an informational paper which does not propose any change to the standard". On to the thesis, with the caveat I'm not a library expert these days, let alone a executor or networking ts. I'm not the right person to review this but I tried! I felt it was a bit a bit one sided, the conclusion of P3941 is

In general *it seems unlikely that all schedulers can be constrained to be infallible*. As a result affine_on and, by extension, task won’t be usable with all schedulers if affine_on insists on using only infallible schedulers. If there are fallible schedulers, there aren’t any good options for using them with a task. Note that affine_on can fail and get cancelled (due to the main work failing or getting cancelled) but `affine_on can still guarantee that execution resumes on the expect execution agent when it uses an infallible scheduler.

I.E it's not saying that scheduling is infallible, rather than there is a mismatch between on one side scheduling can fail, and on the other, we have no clue what to do when scheduling fails (ie we don;t know where to get back to). In fact, my main question here is, LEWG decided in the context of P3941 to have `affine` require an infallible scheduler, which in effect seems to imply a task cannot be executed on a parallel scheduler. Am I correct? And if so, isn't that... limitating? Can that be improved? There was a different suggestion here, that is not mentioned or pondered. Maybe doing so would be informative. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3941r4.html#allow-... Nits: `affine_on` -> `affine` (it was renamed at some point)