- Start an encrypted unauthenticated conversation with the server first: that adds at least one extra round-trip, so most people won't do it, so it's easy to block all connections that do
- Encrypt it to a key you have from the previous connection: doesn't help the initial connection and you already have session resumption for the rest
- Encrypt it to a well-known "private" key: doesn't help at all
The actual proposal for TLS 1.3 SNI seems to involve ... domain fronting. https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 (I assume that's so that it avoids the "it's easy to block" problem)
Eh, people will do whatever the TLS libraries have as default. Optimizing for an extra RT is way above what most app developers do.