TLS + ECH encrypts all message content, including the client hello with the hostname, but it does not encrypt a specific message (an IP address + service identifier combination) that uniquely specifies which program will terminate the TLS connection.
If you want information to be private about the host name you're connecting to, you need not only a single public IP address for many hosts, but also for that server to terminate TLS for all of those hosts.
That's an accurate summary of how TLS+ECH would work with snid.
More generally, I don't think it's required for a single server to terminate TLS for all hosts. If an SNI proxy server knew the private key necessary for decrypting the ECH extension, it could look inside it to determine where to proxy the connection, without having to terminate TLS.
If snid worked this way, the unencrypted SNI hostname wouldn't need to identify the backend, which means that clients connecting over IPv4 would have more privacy. But snid would have to coordinate the ECH encryption key with the backends, which would add a lot of complexity, and IPv6 clients wouldn't benefit in any case.
TLS + ECH encrypts all message content, including the client hello with the hostname, but it does not encrypt a specific message (an IP address + service identifier combination) that uniquely specifies which program will terminate the TLS connection.
If you want information to be private about the host name you're connecting to, you need not only a single public IP address for many hosts, but also for that server to terminate TLS for all of those hosts.