Yeah, I thought I implied that, but that was the reason SNI started - IPv4 is a scarce resource and thus expensive and the only way to host multiple https websites was having multiple IPs (not necessarily multiple servers, you can easily have multiple IPs for one server, you just had to bind one IP per host), which was adding to the costs quite a bit and hobby projects couldn't really afford it (well, they could, but not many people are spending hundreds of dollars for a hobby website).

It's happening as part of the handshake. Probably not completely what it's about, but it was the first that came to my mind.

Edit: It has to happen before the encryption is established, because otherwise the server doesn't know which certificate to use, because it doesn't know which host is the client requesting. There's also ESNI (encrypted SNI) to solve this but I'm not sure on how many servers actually deploy it.

A government will still subpoena the destination IP for the information if they want it.

ECH protects against warrantless monitoring and other non-government bad actors and I'm happy to see it implemented. If there hasn't been a strong enough privacy argument to use Firefox for someone to date, this is a big one.

Is it because of the "Host" HTTP header? I always thought it was optional, since the IP address and port were handled by the network and transport layers respectively. Turns out it's required to resolve between different virtual hosts in the same server. Today I Remembered (TIR?) that virtual hosts are a thing...

Is there anything else that might indicate the domain name in the handshake connection?

That's an option, but its a lot of work and all you get in return is broken apps/websites and not being able to tell if someone is mitm-ing you mitm.

I'm sure some engineer out there is going to find a workaround, hopefully without breaking encryption.