This paper proposes that associated_executor not provide a default candidate type.
The Networking TS  introduces “associators:” Binary class templates whose arguments are the “source type” and the “candidate type” (respectively) (§220.127.116.11 [async.reqmts.associator]). A default (the “default candidate type”) is required to be provided for the “candidate type” (i.e. an associator must be usable as if it were a unary class template).
The purpose of an associator is to obtain an instance of an “associated object” based on a “source object” (an instance of the source type) and optionally a “candidate object” (an instance of the candidate type). The type of the associated object (i.e. the “associated type”) is available through the type member type alias and the actual computation of the associated object may be performed via the get static member function. This member function must be invocable as if it were a unary or binary function (in the unary case only the source object is accepted whereas the binary case accepts both the source object and candidate object).
There are two associators provided by the Networking TS: associated_executor (§13.12 [async.assoc.exec]) and associated_allocator (§13.5 [async.assoc.alloc]) which obtain objects whose types satisfy the Executor (§13.2.2 [async.reqmts.executor]) and ProtoAllocator (§13.2.1 [async.reqmts.proto.allocator]) named type requirements
(respectively). They have default candidate types system_executor and allocator (respectively).
P2149R0  was written in response to discussion in Prague 2020 SG4 which brought the design and usability of system_executor into question. P2149R0 proposed a two pronged solution.