Is this not a valid approach then? The issues of ossification and strict allowance for just known protocols appear to be big enough to cause things like SCTP to not have a viable, widespread use in their future.
I believe that we will see ossification of QUIC eventually too. TCP has been around for decades, anything around that long is going to have issues rolling out new changes in a backwards compatible way. TLS 1.3 and the lengths it had to go to with backwards compatibility with middleboxes is another good example.
I hope that QUIC has used these lessons from TCP and TLS to make changes in the future as easy and effective as possible, but I’m sure it’ll still have its limits.
The IETF QUIC working is well-aware of this, and is attempting to save design room for future QUIC versions as much as possible. The "QUIC invariants" spec documents everything that is guaranteed not to change, but other than than everything in a future QUICv2 could be updated (e.g. tls version, features, large parts of packet header layout).
I fear that unless they are already actively using different values for those updatable values that middleboxes will implement a de facto version of QUIC that “just works” with what is out now, but no regard to gracefully handling forwards-compatibility. Example is the SSL version field which has become static because many implementations didn’t handle an unknown value gracefully.
