But that problem is just session resumption, and that isn't new or specific to 1.3. Another way to do this would be session tickets too (also not new with 1.3). Your client can remove support for both, and always connect as a new connection.

If you're concerned about it, couldn't you turn it off clientside?

Yes. And like so many other behaviours in the web-stack, I feel like I'm in a constant fight with my client software to please choose privacy over convenience. So it's worth being aware of where these tradeoffs exist. Especially when I'm writing that client software.

If you're that paranoid about your privacy, then I recommend you choose a user agent whose philosophy on privacy more closely represents your own.

Tor Browser, for example, is highly likely to "choose privacy over convenience" whenever possible with it's default settings.

How exactly does the client reveal that?

From the spec: "When clients and servers share a PSK (either obtained externally or via a previous handshake), TLS 1.3 allows clients to send data on the first flight (“early data”). The client uses the PSK to authenticate the server and to encrypt the early data."

The client initiating the 0RTT provides a pre-shared key, thus revealing to the server that they're not a newcomer. I don't know exactly how many bits of that PSK could be used by the server to identify specific clients. For QUIC I think it's a 15-bit identifier. Browsers will need to clear the PSK (and so remove the 0-RTT) when they clear cookies or in a "private browsing" mode.

Is there any way to do a 0RTT request for a completely new connection/session?

I mean, if I want to get weather data from let's say NOAA, so a simple GET / HTTP/2, why would I want to send any PSK? Let the server send the response and the Server Cert and the client can decide whether to trust the reply or not.

CloudFlare only "allows" 0RTT for GETs, for example. Is that different, or they also need the PSK?

0-RTT is defined with a PSK (pre-shared key). There are two ways you might have a PSK. The only one that would come up in a web browser as they're constructed today is a "resumption" PSK, agreed between the two parties during a previous connection.

For the Internet of Things it's also envisioned that some devices might know a PSK at the outset to use TLS rather than some custom protocol to secure their traffic. Maybe your lightbulb controller knows a PSK for the lightbulbs baked in at the factory. But it's not expected that web browsers will care about this case.

I'm pretty happy with the strong confidentiality guarantees offered by TLS 1.3, and a finished standard is better than more draft and committee turns, but I think the simple use case of securely accessing "public" information with 0-RTT seems to be left out.

Or simply serving static content faster would have been a nice few percentage efficiency gain.