Function request_streams_beside_the_control_stream 

async fn request_streams_beside_the_control_stream(
    client: &Transport,
    relay: &Transport,
    ctx: &ForwardCtx,
) -> Result<(), ProxyError>

The client-to-relay request-stream loop, for a draft whose control stream is bidirectional and which has request streams as well — draft-16 alone. See bidi_streams_carry_requests.

Why it is a branch of the control stream’s select! and not a task

Because both take bidirectional streams off the same transport, and only one accept may be outstanding if the first one is the control stream is to mean anything. Running here, the loop starts after forward_control_stream has already taken the control stream, so the order is fixed by the code rather than by which task the runtime polled first. A separate task racing the same accept_bi would forward the control stream as a request stream on whichever runs of whichever build happened to lose.

The relay-to-client direction has no such constraint — nothing else accepts a relay-initiated bidirectional stream — so it is spawned as an ordinary loop beside this function’s caller.

On every other draft this never completes, which leaves the select! above decided by the two control pipes exactly as it was before draft-16 had anywhere else to put a request.