Proposed resolution:

This wording is relative to N5032.

1. Modify [exec.on] as indicated:

   -9- Let `out_sndr` be a subexpression denoting a sender returned from `on(sch, sndr)` or one equal to such, and let `OutSndr` be the type `decltype((out_sndr))`. For a pack of subexpressions `env`, get_completion_domain<>(get_env(out_sndr), env...) is expression-equivalent to get_completion_domain<set_value_t>(sch, env...). Let `out_rcvr` be a subexpression denoting a receiver that has an environment of type `Env` such that sender_in<OutSndr, Env> is `true`. Let `op` be an lvalue referring to the operation state that results from connecting `out_sndr` with `out_rcvr`. Calling `start(op)` shall […]

As currently specified, for the expression `on(sch, sndr)`, the starting domain is the receiver's domain, and the (`set_value`) completion domain is `sndr`'s completion domain, given that it starts on `sch`. Those are the two domains that will be used to find customizations of `on`, neither of which is the domain of `sch`.

Presumably, if a user wants to customize `on`, they would expect `on(sch, sndr)` to use the domain of `sch` to find the customization. So there is a gap between what would be least surprising and what is currently specified.

In P3927, we added a get_completion_domain<T> query where `T` could be either a completion tag (`set_value_t`, et. al) or `void` (and defaults to `void`), where get_completion_domain<void> defaults to get_completion_domain<set_value_t>.

get_completion_domain<void>(get_env(sndr), env) is the domain that gets used by `transform_sender` to find a `set_value` sender transform. In other words, `transform_sender(sndr, env)` will, among other things, apply the following transform:

auto sndr2 = get_completion_domain<>(get_env(sndr), env)
                .transform_sender(set_value, forward<Sndr>(sndr), env);

We can use this to query to make `transform_sender` use the domain of `sch` to find a customization of `on(sch, sndr)`.