Original text:
they do not adversely interfere with prioritization performed by existing endpoints or intermediaries that do not understand the newly defined parameter.  Since unknown parameters are ignored, new <del> parameters should not change the interpretation of or modify the predefined parameters in a way that is not backwards compatible or fallback safe. </del>  For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range

Reviewer comments:
We want registration policies that encourage extensions. We also need to bear in mind the existing guidance about how the base scheme, urgency and incremental, are used/applied by clients, servers and intermediaries. The scheme is malleable but it can't implementations are unlikely to be able to swap out prioritization wholesale. This puts reviewers into an awkward position, so we should document clear guidance on registration review and how or when it might be rejected (airing on the side of permissiveness). Fortunately, we had some of these considerations already written down. So this change makes those criteria more specific and actionable. The other important part is that keys are strings, so clashes are less likely. However, given the constraints above and the attractiveness of short key lengths for repeated information, there might be pressure on the finite supply of the 25 remaining single-character keys. So split the IANA registry in two, and place additional Specification Required policy on those precious keys.
First an easy one: Designated Expert is not a standard RFC 8126 rule. I think that you are looking for Expert Review. More substantively, placing a designated expert in a position to consider community feedback is not something we do generally, because it places a lot more responsibility on that person. If the goal is to insist on community review, then you might be better forcing registrations into the standardization process. That said, doing that has historically not worked out well and I would strongly recommend against doing so uniformly, though you might do that for some values (like one-character parameters, for which we have a limited supply) while making policies for other parameters more permissive. It is best if experts are given enough concrete guidance that they aren't ever placed in a position of having to make difficult decisions. Good decisions might cause some people to get angry, for instance. That the decision is good doesn't mean that experts will avoid consequences. Clear, unambiguous guidance to experts is how you avoid those awkward situations.
thank you! I might rewrite this as "future you will thank you for writing down the assessment criteria". We should do this change. We probably want to start thinking about who the expert(s) would be NAME NAME
That's ultimately up to NAME I'd suggest you and/or NAME :)
I am happy to voluteer for that job and if we can share the pain all the better
Same as NAME

Revised text:
they do not adversely interfere with prioritization performed by existing endpoints or intermediaries that do not understand the newly defined parameter.  Since unknown parameters are ignored, new  <ins> parameters should not change the interpretation of, or modify, the urgency (see urgency) or incremental (see incremental) parameters in a way that is not backwards compatible or fallback safe. </ins> For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range