Proposed resolution:

This wording is relative to N5014.

1. Modify [exec.task] as indicated:

   -5- `allocator_type` shall meet the Cpp17Allocator requirements, `scheduler_type` shall model `scheduler`, and `stop_source_type` shall model stoppable-source.

2. Modify [task.state] as indicated:

   void start() & noexcept;
   

   -4- Effects: Effects: Let prom be the object handle.promise(). Associates STATE(prom), RCVR(prom), and SCHED(prom) with `*this` as follows:

   • -4.1- […]
   • -4.2- […]
   • -4.3- […]

   Let `st` be `get_stop_token(get_env(rcvr))`. Initializes prom.token and prom.source such that during lifetime of the asynchronous operation ([exec.async.ops]) associated with `*this`

   • -4.4- prom.token.stop_requested() returns st.stop_requested();
   • -4.5- prom.token.stop_possible() returns st.stop_possible();.
   • -4.6- for types `Fn` and `Init` such that both invocable<Fn> and constructible_from<Fn, Init> are modeled, stop_token_type::callback_type<Fn> models stoppable-callback-for<Fn, stop_token_type, Init>.

[ 2025-12-05 Tomasz comments ]

The paragraph expresses requirements on user supplied `Environment::stop_source_type`, that needs to model stoppable-source, which includes stoppable-callback-for on associated token. We should also require that `Environment::scheduler_type` shall satisfy `scheduler`.

We also need to clarify that `stop_possible` and `stop_requested` on prom.token returns same value as `st` during lifetime of asynchronous operation.

It is not clear what bullet task.state p4.6 is – it reads like a requirement on `stop_token_type`, but if so, this paragraph is a poor place for it.