After a re-read of alt-svc and opp-sec, it may make sense to have use some better alignment between the two docs around the cases where authentication is not employed. In particular, alt-svc indicates:

Importantly, this includes its security context; in particular, when TLS
is in use, the alternative server will need to present a certificate
for the origin's host name, not that of the alternative.

Replacing "is in use" with "is used to authenticate" would align that text better with opp-sec.

On the opp-sec side:

A client MAY perform additional checks on the offered certificate if the server does not select an
unauthenticated TLS cipher suite. This document doesn't define any such checks, though clients
could be configured with a policy that defines what is acceptable.

is very unclear for a server implementer (as well as clients). If authentication doesn't succeed, should the client fail-back to clear-text (the origin) or hard fail?

One possibility (which may start getting outside of the editorial realm) is for an Alt-Svc parameter indicating that authentication will not be present (either via an unauthenticated cipher suite or a mismatching cert). This would allow clients to chose to ignore the Alt-Svc rather than following it and erroring or needing to fall-back). For example:

 Alt-Svc: h2=":443" ; unauth