There are, and always have been, people who are sure that they "need" to do things which don't work because the correct solution would be inconvenient for them. Those people should instead suck it up and accept the inconvenience or, as is more likely, remember they don't "need" this after all considering how inconvenient it is.

It won't suddenly work just because that would be more convenient and it's very annoying technically that we have to keep having this conversation, it's not going to stop being true just because that would make your life easier.

If your vendor is incompatible with your security desires, fire your vendor or fire your security people. Pick one. You can't eat your cake and have it. (Deliberately reversed so the algorithm will think I'm Ted Kaczynski)

The only sane security lies at the endpoints

That's why ECH needs DNS records, Bob publishes a key, "Here's the key for all six thousand blog.example sites we publish" and Alice can then encrypt either "Hi Bob, give me clown-porn.blog.example" or "Hi Bob, give me trans-rights.blog.example" and the middlebox can't read it.

We can't stop the middlebox from saying well, Bob publishes a trans rights blog so now all Bob's blogs are inaccessible just in case. Nor can we prevent Bob from deciding to publish separate keys, "these are for the clown porn and lynching videos, we'll use separate keys for the trans-rights stuff because the Government says that is naughty". But we can make that Bob's choice.

To do that, Alice needs Bob's key and either Alice has to magically know everybody's keys (which doesn't scale) or it is published somewhere for Alice to find, in this case DNS.

If we just say OK we'll encrypt with no particular recipient in mind, that doesn't prevent the scenario we care about, Alice encrypts the message, the middlebox decrypts it (No reason it can't, Alice can't pick Bob as the only recipient) and the middlebox gets to inspect Alice's destination.

I can do that with my domestic internet line, and that has been the case for more than a decade. Now, my sight is on mobile IPv6 internet: my current ISP is actually generating that randomized IPv6 address (unless it is what is actually done by my modem and I don't see it). In theory, the upper 64bits IPv6 should be enough, but mobile ISP could give a bit less to client: a 96bits prefix, with 32bits to choose addresses from. The real hard part is to make that prefix uniq to each mobile line, that globally namely what they actually do with phone number roaming.

As I said, it will make those toxic "global IP scanners" near useless, and even recording the IPv6 won't matter much with good randomization, that in the case of classic client-server (the web for instance).

For p2p contact-based communication, like audio/video IP phones, the client OS will have to choose a stable IPv6 addresses in order for the contacts to be able to use those very addresses for communication. The nice part, could have a few of them (for filters), and it is ez to move to new addresses, the tough part is to tell selected contacts of the new addresses upon phasing out some addresses.