Original text:
1.2. <del> Classic HTTP CONNECT proxies are identified by an origin.  The proxy does not have a path of its own.  This prevents any origin from hosting multiple distinct proxy services. Ordinarily, HTTP allows multiple origin hostnames to share a single server IP address and port number (i.e., virtual-hosting), by specifying the applicable hostname in the "Host" or ":authority" header field.  However, classic HTTP CONNECT proxies use these fields to indicate the CONNECT request's destination (RFC9112), leaving no way to determine the proxy's origin from the request.  As a result, classic HTTP CONNECT proxies cannot be deployed using virtual- hosting, nor can they apply the usual defenses against server port misdirection attacks (see RFC9110). </del>  Classic HTTP CONNECT proxies can be used to reach a target host that is specified as a domain name or an IP address.  However, because

Reviewer comments:
After looking harder, I found that RFC 9110 that a proxy "is usually identified by an "http" or "https" URI". I'm not sure that's 100% accurate, but it conveniently resolves the wording problem, and who am I to argue with RFC 9110?
At the moment, section 1.2 (Problems) start with the following sentence: I totally get what it tries to say, but it is confusing if not incorrect. states that a CONNECT request is handled by a "proxy" and the target specified by the "host:port" tuple is the "origin." Therefore, HTTP CONNECT proxies are not identified by an origin. Rather, they are identified by the user's proxy settings. I think we'd better update the problem statement, and might also consider pointing out that the definition of "origin" will be different between CONNECT and connect-tcp (or use different terms to identify the CONNECT target and the entity that creates a tunnel in order to avoid confusion, maybe?).
PS. Practical example showcasing the side effect of the change to the definition is that the way to authenticate becomes different; when a client tries to establish a CONNECT tunnel with authentication, it uses "proxy-authorization" header, whereas when a client tries to establish a connect-tcp tunnel, it uses "authorization." I think it's worth noting.
I'm realizing that this spec has the opportunity to fix the origin issues present in regular CONNECT. While we're there it'd be great to clarify how connect-tcp interacts with Alt-Svc because it's unclear for CONNECT. I sent some more about why it's unclear for CONNECT.
Thanks for the discussion!

Revised text:
1.2.  <ins> HTTP clients can be configured to use proxies by selecting a proxy hostname, a port, and whether to use a security protocol.  However, CONNECT requests using the proxy do not carry this configuration information.  Instead, they only indicate the hostname and port of the target.  This prevents any HTTP server from hosting multiple distinct proxy services, as the server cannot distinguish them by path (as with distinct resources) or by origin (as in "virtual hosting"). The absence of an explicit origin for the proxy also rules out the usual defenses against server port misdirection attacks (see RFC9110) and creates ambiguity about the use of origin-scoped response header fields (e.g., "Alt-Svc" RFC7838, "Strict-Transport-Security" RFC6797). </ins> Classic HTTP CONNECT proxies can be used to reach a target host that is specified as a domain name or an IP address.  However, because