Alt-Svc and HTTP Extensions

RFC 7838 frames a lot of discussion in terms of resource fetching, which is
supplied equivalently  by the core definitions of HTTP/2 and HTTP/3.
Therefore failure of an Alternative is discussed in terms of connection
errors or 421 (Misdirected Request) HTTP Status Code. But I'm starting to
wonder what expectations are for some classes of HTTP extension.

Lets assume a world where HTTP/2 and HTTP/3 co-exist but development and
deployment of extensions progresses at different rates. For example, right
now we may have HTTP/2 servers that support WebSocket (RFC 8441) but few
HTTP/3 servers that offer a similar extension (both because it is not
formally defined, and because it is not deployed on a fully authoritative
alternative).

A client that is happily using HTTP/2 WebSockets may see an Alt-Svc for
HTTP/3 and eventually decide to switch, only to find that it cannot do
HTTP/3 WebSockets. It could discover this early, because in this case the
extension is negotiated using SETTINGS_ENABLE_CONNECT. Howver, not all
extension require such a negotiation.

So the question is, was it correct or fair for the HTTP/2 server to
advertise the alternative that cannot satisfy the exact same desired
properties of the active connection? It seems like a class of error similar
to Misdirect Request, caused by accidental advertisement due to poor
coordination. However, extensions may not be bound to request/response, so
perhaps there might be some benefit in defining a new error code that
allows an endpoint to reset streams or close connections.

Lucas