Traffic schemes have a principle that once a right of way is established, any competing mode of transport wanting to cross that right of way is responsible for building the necessary bridges etc.
I raise this not to propose it as a principle for the Internet but rather the opposite, to call it out as an anti-pattern.
If the IAB has an architectural role, it is maintaining the thinness of the thin waist: Keeping complexity out of the Internet core is important and requires vigilance.
The anycast over TCP discussion reminds me of a much older argument in the industry when people who got used to hooking MSDOS system calls at particular addresses were wont to scream like banshees each time a new version of MSDOS came out with the entry points moved.
From an architectural point of view, ANYCAST is not a thing, it is a hack. A hack that is useful but one that was never guaranteed to support TCP. The Internet architecture was designed to support UNICAST. The fact that architecture allows us to share an IP address between hosts within a BGN ASN is interesting and useful but not a core commitment by the architecture. If people want to build stuff on that quicksand, so be it. But those who do so have to understand they are building within very limited constraints and there is no long term commitment to support any use they might establish outside those constraints.
Sure, there will be people who have come up with some ingenious scheme that allows systems to work because the deployed infrastructure currently provides stronger guarantees. But fortunately the IETF does not have the ability to insist such guarantees be continued so we really don't have to debate whether we should do something we can't.
The cost of insisting that squatters rights be preserved would be a gradual ossification of the core as every change is required to preserve the rights of the owners of riparian rights.
As for QUIC, Christian is half right. Yes, QUIC does behave in a way that is more compatible with ANYCAST. But QUIC was never designed to work in that way and hence does not guarantee it will work that way.
Fortunately, QUIC is not the replacement for TCP, it is one tool that does the same job and the most important single change in QUIC is that from this point on every application can choose their own transport. The principle that the platform providers are gatekeepers for transport provision has been broken.
Censorship resistant protocols is a very longstanding interest of mine and I would like to see innovation in that area. I really can't see much that ANYCAST brings to the table beyond the discovery phase but Multicast certainly interests me a lot.
There are three types of transport protocol are possible:
121) One to One
12M) One to Many
M2M) Many to Many
The last is of course the holy grail for some people, peer to peer goodness and all that. As an applications guy, I have absolutely no interest in that type of transport, reliable or not. Even when my application is peer to peer.
A reliable transport with DDoS resistance properties supporting 121 and 12M that could make use of multicast and hide the fact it had been used from the application layer would be very very useful.
QUIC arrived at IETF as an optimization that Google was using and wanted to standardize. Which is a completely valid mode of IETF work. But if we want to do interesting stuff, QUIC is not the test bed to build upon. We need to do research first and challenge the prior assumptions baked in before the effort began.
PHB
