Original text:
The "Connection Priority" Connection Property operates on Connections in a Connection Group using the same approach as in msg-priority: when allocating available network capacity among Connections in a <del> Connection Group, sends on Connections with lower Priority values will be prioritized over sends on Connections with higher Priority values.  Capacity will be shared among these Connections according to the Connection Group Transmission Scheduler property (conn- scheduler).  See priority-in-taps for more. </del>  8. 100 <del> This Property is a non-negative integer representing the relative inverse priority (i.e., a lower value reflects a higher priority) of </del>  this Connection relative to other Connections in the same Connection <del> Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned, i.e., changing the Priority on one Connection in a Connection Group does not change it on the other Connections in the same Connection Group.  No guarantees of a specific behavior regarding Connection Priority are given; a Transport Services system may ignore this property.  See priority-in-taps for more details. </del>  8.1.3.

Reviewer comments:
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!
LGTM.

Revised text:
The "Connection Priority" Connection Property operates on Connections in a Connection Group using the same approach as in msg-priority: when allocating available network capacity among Connections in a  <ins> Connection Group, sends on Connections with higher Priority values will be prioritized over sends on Connections that have lower Priority values.  Capacity will be shared among these Connections according to the Connection Group Transmission Scheduler property (conn-scheduler).  See priority-in-taps for more. </ins> 8. 100  <ins> This Property is a non-negative integer representing the priority of </ins> this Connection relative to other Connections in the same Connection  <ins> Group.  A higher value reflects a higher priority.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned, i.e., changing the Priority on one Connection in a Connection Group does not change it on the other Connections in the same Connection Group. No guarantees of a specific behavior regarding Connection Priority are given; a Transport Services system may ignore this property.  See priority-in-taps for more details. </ins> 8.1.3.