Proposed resolution:

This wording is relative to N5008.

1. Modify [exec.snd.expos] as indicated:

   template<class Sndr, class Env>
     constexpr auto get-domain-late(const Sndr& sndr, const Env& env) noexcept;
   

   -14- Effects: Equivalent to:

   1. (14.1) — If sender-for<Sndr, continues_on_tschedule_from_t> is `true`, then

      return Domain();
      

      where `Domain` is the type of the following expression:

      [] {
        auto [_, sch, _] = sndr;
        return query-or-default(get_domain, sch, default_domain());
      }();
      

      [Note 1: The continues_onschedule_from algorithm works in tandem with schedule_fromcontinues_on ([exec.schedule.from][exec.continues.on]) to give scheduler authors a way to customize both how to transition onto (continues_onschedule_from) and off of (schedule_fromcontinues_on) a given execution context. Thus, continues_onschedule_from ignores the domain of the predecessor and uses the domain of the destination scheduler to select a customization, a property that is unique to continues_onschedule_from. That is why it is given special treatment here. — end note]

   2. […]

The reason for having two different customization points for transitioning between two execution contexts is described in [exec.snd.expos] bullet (14.1) Note 1, to wit:

[Note 1: The `continues_on` algorithm works in tandem with `schedule_from` ([exec.schedule.from]) to give scheduler authors a way to customize both how to transition onto (`continues_on`) and off of (`schedule_from`) a given execution context. Thus, `continues_on` ignores the domain of the predecessor and uses the domain of the destination scheduler to select a customization, a property that is unique to `continues_on`. That is why it is given special treatment here. — end note]

The exposition-only get-domain-late function treats `continues_on` senders specially to make sure the correct domain (that of the destination scheduler) is used to find customizations at connect time.

However, customizations are also searched for early when the sender is first constructed. And here the dispatching of `continues_on` and `schedule_from` are reversed.

`continues_on(sndr, sch)` is defined as ([exec.continues.on]):

transform_sender(get-domain-early(sndr), make-sender(continues_on, sch, sndr))

which is using the domain of the predecessor rather than ignoring it as [exec.snd.expos] p14.1 says it does. And `schedule_from(sch, sndr)` is currently defined as ([exec.schedule.from]):

transform_sender(
  query-or-default(get_domain, sch, default_domain()),
  make-sender(schedule_from, sch, sndr))

which is using the domain of the destination scheduler to find customizations. The logic for determining the domain to use for early customization of these two algorithms are opposite what they are for late customization. This is a bug. They should be consistent.

"Lazy" customization (at connect time) was added to P2300 later in the process, and this inconsistency was a mistake on my part. The correct thing to do is to change get-domain-late to treat `schedule_from` as special, not `continues_on`.