Description
The get_stop_token query used to be found at std::execution::get_stop_token but is currently specified to be found at std::get_stop_token.
Presumably this change was made because of an intent to be able to apply it to things unrelated to std::execution and sender/receiver.
However, the semantics of this query are tightly coupled with the concept of receiver environments and the sender/receiver contract. e.g. a stoppable_token obtained from a given receiver's environment is only guaranteed to be valid until either the operation-state is destroyed or until a completion-operation is invoked on that receiver. Further, all stop-callbacks must be deregistered before invoking a completion-operation on the receiver.
The argument to get_stop_token() is named env, implying that it is an "environment" obtained via std::execution::get_env().
I gather we decided to put get_env into the std::execution namespace to distinguish it from the existing std::getenv function.
Since get_stop_token is defined in terms of the get_env functionality it tends to imply that they are part of the same facility and so should probably be defined in the same namespace.
Also, the specification of std::get_stop_token is has an overload that takes no arguments that is defined in terms of std::execution::read(), which also seems to imply that this facility is a std::execution-specific facility rather than a general facility.
Should we reconsider the decision to move get_stop_token from std::execution to the std namespace?