Yes. And the major * 10000 + minor convention is used in other places already, for PG versions, so it might already be familiar to some people.
I'm wondering why we are indicating that minor versions of the protocol are even a real thing. We should just use integer version numbers. We are on 3. The next one is 4 (the trailing .0 is just historical cruft just like with our 3-digit PostgreSQL version number).
v18 libpq-based clients, if they attempt to connect using v4 and fail, will try again using the v3 connection. That will retain status quo behavior when something like a connection pooler doesn't understand the new reality. We can add a libpq option to prevent this auto-downgrade behavior.
At some point users will want to use something other than the v3 current tooling supports and will put pressure on those tools to change. In the mean-time our out-of-the-box behavior continues to work using the v3 protocol.
Feature detection sounds great, and maybe we want to go there eventually, but everyone understands progressive enhancement represented by version numbering. A given major server version would only support a fixed and unchanging set of protocol versions between 3 and N. On the client, if N = 7 then libpq would be able to choose both 7 and 3 as the version it tries out-of-the-box. We can use a libpq parameter to allow the client to specify something between 4 and 6 (which may fail depending on poolers and what-not). If the chain of servers supports protocol version negotiation then the attempt to connect using 7 can be auto-downgraded to anything between 3 and 6 (saving effort of a failed attempt and establishing a new one.) Leaving the client the option to specify a minimum version of the protocol it can accept.
