Consider passing an env with the current execution context to start/set_xxx methods

[lewissbaker]

Sometimes an operation will need to do different things depending on which execution context the prior operation completes on. However there isn't currently an easy way to determine which context you completed on.

The get_completion_scheduler() query only lets you report a single scheduler which doesn't help if an operation could potentially complete on one of several different schedulers. e.g. when_all() could complete on any of the contexts of the input senders.

One avenue that may be worth exploring is having execution contexts explicitly pass information about the current context to start() and also to set_value, etc. methods. This way these operations can know on what context they are starting/completing by querying the environment for the scheduler.

The beginnings of a prototype exploring this idea can be found here: https://godbolt.org/z/537dcerjo

There are a number of outstanding problems a potential design here would need to solve, however.

• how to pass the context through stop-requests
• how to pass through type-erasing layers - may require including the completion-context environment types in the completion-signatures.

[lewissbaker]

I think this is too big a change to be making at this stage, even if we had a mature design ready and proven out (which we don't). Closing as wont-fix.