Original text:
create a new stream on the given Connection, then attempts to clone a connection will result in a CloneError: <del> The Protocol Property "Niceness" operates on entangled Connections as in msg-niceness: when allocating available network capacity among </del>  Connections in a Connection Group, sends on Connections with higher <del> Niceness values will be prioritized over sends on Connections with lower Niceness values.  An ideal transport system implementation </del>  would assign each Connection the capacity share (M-N) x C / M, where <del> N is the Connection's Niceness value, M is the maximum Niceness value </del>  used by all Connections in the group and C is the total available <del> capacity.  However, the Niceness setting is purely advisory, and no </del>  guarantees are given about the way capacity is shared.  Each implementation is free to implement a way to share capacity that it sees fit. Integer (non-negative) <del> This property represents an unbounded hierarchy of priorities.  It can specify the priority of a Message, relative to other Messages sent over the same Connection. </del>  <del> A Message with Niceness 0 will yield to a Message with Niceness 1, which will yield to a Message with Niceness 2, and so on.  Niceness </del>  may be used as a sender-side scheduling construct only, or be used to specify priorities on the wire for Protocol Stacks supporting prioritization. Note that this property is not a per-message override of the <del> connection Niceness - see conn-niceness.  Both Niceness properties </del>  may interact, but can be used independently and be realized by different mechanisms. this property. Note that a Final Message must always be sorted to the end of a list <del> of Messages.  The Final property overrides Niceness and any other </del>  property that would re-order Messages.  If another Message is sent after a Message marked as Final has already been sent on a Connection, the Send Action for the new Message will cause a support removing a Message from its buffer, this property may be ignored. <del> Niceness: this represents the ability to de-prioritize a Message in favor of other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different niceness on streams of different priority. </del>  Ordered: when this is false, it disables the requirement of in- order-delivery for protocols that support configurable ordering. and UDP.  Below, we amend this description for other protocols (if applicable): <del> Relative niceness: for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. </del>  Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of

Reviewer comments:
Not many text fixes needed - quite a bit of text reflected the old choice of Priority anyway and wasn't correctly updated for Niceness :-)
At 8.1.2 you say lower values have higher priorities for connPrio. But later, at msgPrio, higher values have higher priority, and in the examples where you speak of the interaction of connPrio and msgPrio, you imply that higher means higher for both properties. Please check for consistency and clarify.
Lower values having higher priorities for connPrio is a remnant that we must have missed when we flipped this, e.g. PR which I don't know... too many iterations have mangled the text.
Aha, now I see what happened: following some more PRs, also , in PR , NAME re-introduced some text saying that sends on Connections with lower-priority values will be prioritized over sends on Connections with a higher-priority value. This reverses the logic for some part of the text - I suspect that NAME (very understandably!) forgot what happened and this created this mix. We have been editing these documents for way too long!
Fine with me. The max_prio problem can be addressed separately.

Revised text:
create a new stream on the given Connection, then attempts to clone a connection will result in a CloneError:  <ins> The Protocol Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among </ins> Connections in a Connection Group, sends on Connections with higher  <ins> Priority values will be prioritized over sends on Connections with lower Priority values.  An ideal transport system implementation </ins> would assign each Connection the capacity share (M-N) x C / M, where  <ins> N is the Connection's Priority value, M is the maximum Priority value </ins> used by all Connections in the group and C is the total available  <ins> capacity.  However, the Priority setting is purely advisory, and no </ins> guarantees are given about the way capacity is shared.  Each implementation is free to implement a way to share capacity that it sees fit. Integer (non-negative)  <ins> This property represents a hierarchy of priorities.  It can specify the priority of a Message, relative to other Messages sent over the same Connection. </ins>  <ins> A Message with Priority 0 will yield to a Message with Priority 1, which will yield to a Message with Priority 2, and so on.  Priorities </ins> may be used as a sender-side scheduling construct only, or be used to specify priorities on the wire for Protocol Stacks supporting prioritization. Note that this property is not a per-message override of the  <ins> connection Priority - see conn-priority.  Both Priority properties </ins> may interact, but can be used independently and be realized by different mechanisms. this property. Note that a Final Message must always be sorted to the end of a list  <ins> of Messages.  The Final property overrides Priority and any other </ins> property that would re-order Messages.  If another Message is sent after a Message marked as Final has already been sent on a Connection, the Send Action for the new Message will cause a support removing a Message from its buffer, this property may be ignored.  <ins> Priority: this represents the ability to prioritize a Message over other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different Priority on streams of different priority. </ins> Ordered: when this is false, it disables the requirement of in- order-delivery for protocols that support configurable ordering. and UDP.  Below, we amend this description for other protocols (if applicable):  <ins> Priority (Connection): for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. </ins> Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of