Original text:
will never show up when queuing the value of a preference - the effective preference must be returned instead. <del> The implementation MUST ensure a consistent outcome given the same Selection Properties.  Internally, it MUST exclude all protocols and paths that match a Prohibit and exclude all protocols and paths that do not match a Require.  It MUST then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker. Note that the protocols and paths which are available on a specific system may vary, such that application preferences may conflict with each other.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not available on the preferred path.  In such cases, implementations MUST ensure a deterministic outcome by prioritizing Selection Properties that select paths over those that select protocols.  Therefore, the transport system MUST try the path first, ignoring the protocol preference if the protocol does not work on the path. </del>  Selection and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the section is the algorithm defining which of these options to try, when, and in what order.  4.1. The step of gathering candidates involves identifying which paths, properties, it should only keep branches that satisfy these requirements.  Finally, it should order branches according to preferred properties, and finally use avoided properties as a <del> tiebreaker. </del>  4.4.

Reviewer comments:
In the , people found the normative language in too restrictive and agreed with the original suggestion in . Therefore, this PR moves the selection algorithm text to the implementation draft and removes some normative language in the interface draft. We still want to provide consistency to applications when possible, so there's a sentence in the implementation draft on this now as well.
LGTM modulo the suggestion from NAME which I would accept as-is Great with one minor knit.

Revised text:
will never show up when queuing the value of a preference - the effective preference must be returned instead.  <ins> The implementation MUST ensure an outcome that is consistent with application requirements as expressed using Require and Prohibit. While preferences expressed using Prefer and Avoid influence protocol and path selection as well, outcomes may vary given the same Selection Properties, as the available protocols and paths may vary across systems and contexts.  However, implementations are RECOMMENDED to aim to provide a consistent outcome to an application, given the same Selection Properties. Note that application preferences may conflict with each other.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not available on the preferred path.  In such cases, implementations SHOULD prioritize Selection Properties that select paths over those that select protocols.  Therefore, the transport system SHOULD race the path first, ignoring the protocol preference if the protocol does not work on the path. </ins> Selection and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the section is the algorithm defining which of these options to try, when, and in what order. <ins> During Candidate Gathering, an implementation first excludes all protocols and paths that match a Prohibit or do not match all Require properties.  Then, the implementation will sort branches according to Preferred properties, Avoided properties, and possibly other criteria. </ins> 4.1. The step of gathering candidates involves identifying which paths, properties, it should only keep branches that satisfy these requirements.  Finally, it should order branches according to preferred properties, and finally use avoided properties as a  <ins> tiebreaker.  When ordering branches, an implementation may give more weight to properties that the application has explicitly set than to properties that are default. As the available protocols and paths on a specific system and in a specific context may vary, the result of sorting and the outcome of racing may vary even given the same Selection and Connection Properties.  However, an implementation ought to aim to provide a consistent outcome to applications, e.g., by preferring protocols and paths that existing Connections with similar Properties are already using. </ins> 4.4.