`std::this_thread::sync_wait` from P2300
<https://isocpp.org/files/papers/P2300R10.html#spec-execution.senders.consumers.sync_wait>
works by creating an internal `run_loop`, connecting the provided sender
with an internally created receiver, starting the resulting operation
state, and then calling the `run` method on the `run_loop`
([exec.sync.wait])

Now suppose we have a very simple sender that, when connected to a receiver
and started, eagerly calls `set_value` on the receiver. That means as soon
as the operation state starts, the receiver will get the completion signal
and call `finish`. Then when `run` is later called as shown in
[exec.sync.wait] paragraph 6, it will violate the precondition of `run`
(you can't call `run` unless the `run_loop` is in the "starting" state).

Did I misunderstand something?

I could imagine this working if there were a step that first calls
`starts_on` and then connects the resulting sender to the receiver, so that
when the resulting operation state starts, it merely enqueues the work on
the `run_loop` instead of actually doing it. But I don't see this being
described anywhere in the wording.

-- 
*Brian Bi*