Proposed resolution:

This wording is relative to N5014.

1. Modify [exec.connect] as indicated:

   [Drafting note: This should cover the design intent, although we may want to spell this out more explicitly in terms of the exact semantics in a similar way to [coro.generator.promise] p17, which lists overloads of operator `new()` and describes the rebound allocator type which allocates storage in chunks of size `__STDCPP_DEFAULT_NEW_ALIGNMENT__`.]

   -5- Let `V` name the type await-result-type<DS, connect-awaitable-promise>, let `Sigs` name the type

   […]
   

   and let connect-awaitable be an exposition-only coroutine defined as follows:

   namespace std::execution {
     […]
   }  
   

   Any dynamically allocated storage required for the coroutine state allocated by an invocation of the form connect-awaitable(sndr, rcvr) is allocated using the allocator obtained from `get_allocator(get_env(rcvr))`.

   -6- […]

The wording for `connect()` ([exec.connect]) handles passing awaitable types as the sender argument by calling the connect-awaitable() coroutine and having it execute a `co_await` expression.

The connect-awaitable() coroutine will typically need to dynamically allocate storage for the coroutine state and, as specified, this currently just always uses the global default allocator. This is because the connect-awaitable-promise type does not define any member operator `new/delete` overloads.

It seems desirable for this facility to use the allocator obtained from the receiver, by calling `get_allocator(get_env(rcvr))`, in order to allocate storage for the coroutine-state instead of always using global operator `new`. This would give the user at least some level of control over how this allocation is performed.