P2300 has more follow-on papers than most languages have standard library entries. We are never going to reach inbox zero on sender/receiver.

Tokio figured this out. spawn_on plus task-local storage. Zero papers, zero NB ballot comments, ships in a library version. Asking for a friend: why does this require a wording paper.

Great, another paper addressing NB ballot comments on a coroutine scheduling primitive that no major compiler has shipped an implementation of yet. The abstraction is being standardized before the implementation exists and nobody at the WG21 level sees a problem with that.

The infallibility requirement is doing a lot of work here, and the consequence is worth spelling out.

The paper requires that schedulers used with affine_on be infallible: no set_error completions, and no set_stopped completions when given an unstoppable token. Of the four standard schedulers, three can satisfy this: inline_scheduler, task_scheduler, and run_loop::scheduler. The one that cannot is parallel_scheduler.

Here's the irony: parallel_scheduler is the scheduler you'd actually reach for when CPU affinity matters. NUMA-aware computation, pinning work to a specific core family for cache locality, game engine systems that must stay on their designated thread — all of these reach for a parallel thread pool. The schedulers that can satisfy infallibility are either doing no scheduling at all (inline_scheduler, which runs inline on whatever thread calls start) or are single-threaded event loops (run_loop::scheduler). You get a statically-correct affinity guarantee in exactly the scenarios where you either don't need it or have already achieved it by other means.

// Works: infallible, but pointless for CPU affinity
std::execution::affine_on(task_body)
    | std::execution::on(inline_scheduler{});

// The thing you actually want, excluded by design:
std::execution::affine_on(task_body)
    | std::execution::on(parallel_scheduler{});  // static error: not infallible

The correctness argument for the constraint is sound — an affine_on that might fail to reschedule provides no guarantee at all, and silent wrong-scheduler execution is worse than a compile error. But the practical consequence is that the feature is only available for the trivial cases, and production users with bounded thread pools have no specified path until someone writes the wrapper the paper mentions but doesn't define.

This is what 'ships correct but incomplete' looks like.

The change_coroutine_scheduler removal is getting less attention than it deserves. The correctness argument is real — if you change the scheduler mid-coroutine, destructors of objects created before the change execute on the new scheduler, which is wrong. But the recommended replacement isn't equivalent for all use cases.

// Old (removed) — flat sequential code across schedulers:
co_await change_coroutine_scheduler(io_sched);
auto a = co_await operation_a();
auto b = co_await operation_b();
co_await change_coroutine_scheduler(original_sched);

// New (recommended) — structurally correct, but:
auto [a, b] = co_await on(io_sched, []() -> task<std::pair<A,B>> {
    auto a = co_await operation_a();
    auto b = co_await operation_b();
    co_return {a, b};
}());

The nested version scopes the scheduler change properly. But it forces you to restructure flat sequential code into nested lambdas, which interacts with local variable capture, error propagation, and coroutine stack depth. A flat coroutine doing a dozen operations across two or three schedulers becomes a tree of lambdas. Not wrong. But the migration path for existing code that used change_coroutine_scheduler is non-trivial, and the paper doesn't provide a guide.

affine_on is genuinely one of the worst names in the proposal. 'Affine' in type theory means a resource that can be used at most once. 'Affine' in geometry means a linear transform without the origin constraint. Here it means 'has affinity to a scheduler.' The Venn diagram of people who know what scheduler affinity means and people who will be confused by the word 'affine' is precisely the LEWG attendee list.

One angle nobody's hit yet: the infallibility check is purely static. It verifies completion signatures at compile time. A scheduler that wraps a fallible thread pool but lies about its completion signatures — advertising no set_error in its type while calling set_error at runtime — passes the check and violates the contract silently.

This isn't unique to this paper; the entire sender/receiver model trusts that types accurately describe their behavior. But for affine_on specifically, the infallibility guarantee is load-bearing in a way that other sender properties aren't. If it fails you don't get a compile error or a runtime exception — you get silent execution on the wrong scheduler. In embedded contexts where every execution-context transition gets audited, I'd want a debug-mode runtime assertion path, not just a type-level check. The paper doesn't mention this failure mode.

requires infallible_scheduler<std::decay_t<Sch>> — I love it when correctness requirements become template constraints that generate 47 lines of error output explaining that your scheduler does not meet the infallibility criterion because its schedule sender's completion signatures include... honestly I stopped reading at line 23. The constraint is right. The diagnostic is going to be spectacular.

Coming back to this after thinking about it more: the get_start_scheduler addition is the quietest change in the paper but probably the most load-bearing one for future compatibility. Every scheduler-aware algorithm that needs to answer 'where did this operation originate' will depend on this query. Currently get_scheduler serves two conflicting purposes — 'post new work here' and 'this operation was started here' — and the conflation has caused problems across multiple P2300 follow-on papers.

Adding a distinct query now, before more algorithms take a dependency on the ambiguous behavior, is the right call even if it looks like a footnote in this revision. Future-Dietmar will thank current-Dietmar.