Right now, the draft is written with the idea that establishing a Reverse HTTP connection is an implicit signal that the origin would prefer the intermediary to use this connection instead of standard forward HTTP. That seems sensible for low traffic, single-instance situations and cases where forward HTTP is not working at all, but there are also situations where this doesn't make sense. For example, if the intermediary is load-balaning across 100 instances for the origin, we probably don't want all traffic to suddenly flip onto the first Reverse HTTP connection that is established.
Right now, the draft is written with the idea that establishing a Reverse HTTP connection is an implicit signal that the origin would prefer the intermediary to use this connection instead of standard forward HTTP. That seems sensible for low traffic, single-instance situations and cases where forward HTTP is not working at all, but there are also situations where this doesn't make sense. For example, if the intermediary is load-balaning across 100 instances for the origin, we probably don't want all traffic to suddenly flip onto the first Reverse HTTP connection that is established.
Needs more input.