Original text:
Remote Endpoint and the Local Endpoint, such as IP addresses resolved from a DNS hostname. <del> 4.2.3. </del>  While some transports expose a byte stream abstraction, most higher level protocols impose some structure onto that byte stream.  That

Reviewer comments:
Satisfies , including text for both generic protocol equivalence and security protocols. We may want to move the section around organizationally later, as per some of Gorry's comments on structure. However, I reference terms from our concept definitions, so it is easier to write in the latter portion of the document.
And add a subsection specifically for security protocols. Determining what security protocols (and configurations) are equivalent is nontrivial and incredibly important if we are to race, e.g., TLS and gQUIC.
I think the racing/gathering section needs a tiny little explanation text and this seems reasonable to add - if you add to this section, can you also make sure it mentions something of the terms "policy" and "cached state" as a part of this update?
NAME yes, will do!
Addressed by .
tiny editorial nits on section refs otherwise this is good to goLGTM!

Revised text:
Remote Endpoint and the Local Endpoint, such as IP addresses resolved from a DNS hostname.  <ins> 4.3. The Transport Services architecture defines a mechanism that allows applications to easily use different network paths and Protocol Stacks.  Transitioning between different Protocol Stacks may in some cases be controlled by properties that only change when application code is updated.  For example, an application may enable the use of a multipath or multistreaming transport protocol by modifying the properties in its Pre-Connection configuration.  In some cases, however, the Transport Services system will be able to automatically change Protocol Stacks without an update to the application, either by selecting a new stack entirely, or racing multiple candidate Protocol Stacks during connection establishment.  This functionality can be a powerful driver of new protocol adoption, but must be constrained carefully to avoid unexpected behavior that can lead to functional or security problems. If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent". Equivalent Protocol Stacks must meet the following criteria: Both stacks must offer the same interface to the application for connection establishment and data transmission.  For example, if one Protocol Stack has UDP as the top-level interface to the application, then it is not equivalent to a Protocol Stack that runs TCP as the top-level interface.  Among other differences, the UDP stack would allow an application to read out message boundaries based on datagrams sent from the Remote Endpoint, whereas TCP does not preserve message boundaries on its own. Both stacks must offer the same transport services, as required by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP.  However, if the application does not require reliability, then a Protocol Stack that adds unnecessary reliability might be allowed as an equivalent Protocol Stack as long as it does not conflict with any other application-requested properties. Both stacks must offer the same security properties.  See the security protocol equivalence section below for futher discussion (security-equivalence). 4.3.1. The inclusion of transport security protocols I-D.ietf-taps- transport-security in a Protocol Stack adds extra restrictions to Protocol Stack equivalence.  Security features and properties, such as cryptographic algorithms, peer authentication, and identity privacy vary across security protocols, and across versions of security protocols.  Protocol equivalence should not be assumed for different protocols or protocol versions, even if they offer similar application configuration options. To ensure that security protocols are not incorrectly swapped, Transport Services systems should only automatically generate equivalent Protocol Stacks when the transport security protocols within the stacks are identical.  Specifically, a system should consider protocols identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport protocol stacks may be considered equivalent, whereas TLS 1.2 and TLS 1.3 I-D.ietf-tls-tls13 should not be considered equivalent. 4.4. </ins> While some transports expose a byte stream abstraction, most higher level protocols impose some structure onto that byte stream.  That