Code change:
suboptimal, particularly if one endpoint operates in ignorance of the needs of its peer. <del> HTTP/2 introduced a complex prioritization signaling scheme that used a combination of dependencies and weights, formed into an unbalanced tree.  This scheme has suffered from poor deployment and </del> <ins> HTTP/2 introduced a complex prioritization scheme that uses a combination of stream dependencies and weights to describe an unbalanced tree.  This scheme has suffered from poor deployment and </ins> interoperability. <del> The rich flexibility of client-driven HTTP/2 prioritization tree building is rarely exercised.  Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </del> <ins> Clients build an HTTP/2 prioritization tree through a series of individual stream relationships, which are transferred to the server using HTTP/2 priority signals in either of three forms.  First, a HEADERS frame with the PRIORITY flag set is an explicit signal that includes an Exclusive flag, Stream Dependency field, and Weight field.  Second, a HEADERS frame with no PRIORITY flag is an implicit signal to use the default priority.  Third, the PRIORITY frame, which is always explicit since it always contains an Exclusive flag, Stream Dependency field, and Weight field. The rich flexibility of tree building is rarely exercised. Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </ins> Many HTTP/2 server implementations do not include support for the priority scheme.  Some instead favor custom server-driven schemes

Related discussion:
text: However, that's going to be a bit complicated, because SETTINGS is a frame that is sent by the two endpoints before receiving one from the peer. Therefore, the minimal mechanism would be something like each endpoint sending a list of schemes that it supports, and then both endpoint choose a scheme from a intersection of the two lists using a predefined logic (e.g., client's list of schemes are ordered by its preference, and the most preferred one also supported by the server will be selected). But before designing a negotiation scheme, I think it's worth asking one question: do we want a negotiation scheme for HTTP/3? If the answer is no, I'm not sure if we need something more than a deprecation scheme for HTTP/2, when what we are trying to do is a back port from HTTP/3. Even with HTTP/2, there's isn't a necessity to negotiate the prioritization scheme. IIRC, the two reasons we introduced the deprecation flag (which IMO is an optimization) are: to reduce the burden of setting up the h2 prioritization tree on the server-side to conserve bandwidth All that said, I think my argument is that having deprecation flag is a good way to punt to the future the cost of designing a solution that we might not need. Because the deprecation flag makes h2 and h3 on par. If we find that we need to replace the new prioritization scheme in the future, then we could introduce a negotiation scheme that works for both H2 and H3. Note also that the new prioritization scheme is extensible.
Not needing to fully specify how they're selected right now is certainly a valid point. But the only difference between a deprecation flag and an indication of support is the orientation of the default value. In HTTP/2, the orientation is that the peer might support that feature, but many don't. So there's value in being explicit both directions; the honest choice for default is "don't know." Indicating support for each scheme gives us more leeway in the future, and we can recommend that implementations which don't support the old scheme explicitly disavow it.
Regarding default, I tend to believe that it should be "supportsh2priorities," because clients should continue sending h2 priorities to h2 servers that do not implement the new extension. That leaves us to the discussion of orientation.