The distinction is deliberate, precisely because it facilitates using a single URI template for both protocols. As discussed in Section 5.3, the client can use a single template for various purposes by inspecting the variables that it contains:

• "target_port" -> connect-udp
• "tcp_port" -> connect-tcp
• "ipproto" -> connect-ip
• "dns" -> DoH

Using the same name ("target_port") for TCP and UDP would add complexity for client implementors. Instead of being able to determine a priori whether a proxy supports TCP and UDP based on the template, the client would have to probe (and periodically re-probe) for this information and maintain dynamic state about which protocols are supported.

What you're saying is that a client can infer support for certain protocols based on the variables present in the URI template. That's not correct, or more precisely it wasn't specified for connect-udp, and it definitely doesn't work for connect-ip (in connect-ip the variables are optional).

OK, I see that it doesn't work for connect-ip, so connect-ip can only be supported by probing or with an out-of-band signal (or with an ecosystem restriction that connect-ip servers must support "target" and "ipproto").

It seems fine for connect-udp and connect-tcp because the variables are mandatory, so it would provide value to UDP+TCP clients (which seem likely to be common).

In that case we should state somewhere that passing around an URI template with these variables implies support for the corresponding mechanism. I'm not sure we'd get consensus on that though.