TL;DR: modelling the stock market incorrectly with a normal distribution leads to the conclusion that the current circumstances arise once every 43 thousand years.

However you do it, it's a matter of "who watches the watchers?"

If everyone is working with good intent then this doesn't matter. But the real world is full of unconscious 'isms so I suspect there's a risk that underrepresented folks are more likely to trip the extra process flag and thereby get slowed down disproportionately, leading to negative feedback loops.

I discovered this week, while the paper was being reviewed by SG1, that I've accidentally stumbled into tackling a rather important problem. Senders as shipped in C++26 can really only express the async equivalent of inline functions because, except for `task`, all the standard senders fully encode the shape of their computation in their type. With something like the `function` I'm proposing, you can use senders to express async algorithms that are separately compiled, just like sync functions.

If the feature lands in a shape similar to what I've proposed in P4223R0, then I think an obvious extension is to modify the core language to support a newer kind of "coroutine" that allows you to define a sender with imperative code. My vision here is that we act on the observation that `std::execution` is a language feature implemented in the library by teaching the compiler how to turn imperative C++ with `co_await`s sprinkled through it into the corresponding sender and operation state. I think this would open the door to putting async object lifetime analysis and optimization where it belongs (in the compiler) without the overheads and inconveniences of C++20 coroutines. It would even let us apply the inliner to async functions when the compiler can see the body of an async callee, not just its declaration.

For now, my next step is to write P4223R1 to incorporate feedback from this past week's WG21 meeting, and continue exploring the design space around specifying sender attributes for a `function`—I'm thinking the current approach of specifying query function signatures needs to be replaced with a key-value object like receiver environments, but I'm not sure yet what consequences that change would have on the design.