Encrypted SNI seems to be tailor made for this situation. The public portion of the request SNI would just be s3.amazonaws.com but the ESNI extension has the full subdomain name. That (+encrypted dns) solves the privacy issue, while still enabling all the new features and improvements they have planned.
Does encrypted SNI solve the issues that AWS are trying to solve by removing path-style S3 requests? Namely, removing the complexity and single-point-of-failure of having one domain, and making it possible for subdomains to have varying allowed cipher settings? I don't know how encrypted SNI will work, but it surely it must choose the cipher before it sends the domain, so it ought to rule out one of the reasons for the change?
According to https://tools.ietf.org/html/draft-ietf-tls-esni-03 ESNI parameters (e.g. public key) are queried via DNS. In the above case, the browser queries a TXT record for _esni.tiananmen-square-facts.s3.amazonaws.com, in addition to A and/or AAAA records for tiananmen-square-facts.s3.amazonaws.com. It then uses the public and other parameters to encrypt the SNI.
So it simply shifts the problem to DNS. To keep requests confidential from sniffers on your LAN or somewhere along the path, you're expected to use something like DoH.
