Code change:
3.3. <del> The Transport Services API is envisioned as the abstract model for a family of APIs that share a common way to expose transport features and encourage flexibility.  The abstract API definition I-D.ietf- taps-interface describes this interface and how it can be exposed to application developers. Implementations that provide the Transport Services API I-D.ietf- taps-impl will vary due to system-specific support and the needs of the deployment scenario.  It is expected that all implementations of Transport Services will offer the entire mandatory API.  All implementations are expected to offer an API that is sufficient to use the distilled minimal set of features offered by transport protocols I-D.ietf-taps-minset, including API support for TCP and UDP transport.  However, some features provided by this API will not be functional in certain implementations.  For example, it is possible that some very constrained devices might not have a full TCP implementation beneath the API. To preserve flexibility and compatibility with future protocols, top- level features in the Transport Services API ought to avoid referencing particular transport protocols.  The mappings of these API features to specific implementations of each feature is explained in the I-D.ietf-taps-impl along with the implications of the feature on existing protocols.  It is expected that I-D.ietf-taps-interface will be updated and supplemented as new protocols and protocol features are developed. </del> <ins> A Transport Services implementation can select Protocol Stacks based on the Properties communicated by the application.  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 are defined as stacks that can provide the same transport properties and interface expectations as requested by the application. The following two examples show non-equivalent Protocol Stacks: If the application requires preservation of message boundaries, a Protocol Stack that runs UDP as the top-level interface to the application is not equivalent to a Protocol Stack that runs TCP as the top-level interface.  A UDP stack would allow an application to read out message boundaries based on datagrams sent from the remote system, whereas TCP does not preserve message boundaries on its own, but needs a framing protocol on top to determine message boundaries. If the 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. The following example shows equivalent Protocol Stacks: If the application does not require reliable transmission of data, then a Protocol Stack that adds reliability could be regarded as an equivalent Protocol Stack as long as providing this would not conflict with any other application-requested properties. To ensure that security protocols are not incorrectly swapped, Transport Services systems MUST only select Protocol Stacks that meet application requirements (I-D.ietf-taps-transport-security).  Systems SHOULD only race Protocol Stacks where the transport security protocols within the stacks are identical.  Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of secure protocols.  A Transport Services system MAY allow applications to explicitly specify that fallback to a specific other version of a protocol is allowed, e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not available. 3.4. </ins> It is important to note that neither the Transport Services API I- D.ietf-taps-interface nor the Implementation document I-D.ietf-taps- impl define new protocols or protocol capabilities that affect what is communicated across the network.  Use of a Transport Services <del> system does not require that a peer on the other side of a connection </del> <ins> system MUST NOT require that a peer on the other side of a connection </ins> uses the same API or implementation.  A Transport Services system <del> acting as a connection initiator can communicate with any existing system that implements the transport protocol(s) selected by the Transport Services system.  Similarly, a Transport Services system acting as a listener can receive connections for any protocol that is supported by the system from existing initiators that implement the protocol, independent of whether the initiator uses Transport Services as well or not. </del> <ins> acting as a connection initiator is able to communicate with any existing system that implements the transport protocol(s) and all the required properties selected by the Transport Services system. Similarly, a Transport Services system acting as a listener can receive connections for any protocol that is supported by the system from existing initiators that implement the protocol, independent of whether the initiator uses a Transport Services system or not. In normal use, a Transport Services system SHOULD result in consistent protocol and interface selection decisions for the same network conditions given the same set of Properties.  This is intended to provide predictable outcomes to the application using the API. </ins> 4.

Related discussion:
text: This is intended to provide predictable outcomes to the application using the transport service. I would then suggest to use lower case within other parts of the document - except were pointed to from here, (we could refer to the requirements subsection, if we thought necessary).
for discussion at the interim, but IMO we could start the interim with a PR based on these suggestions and work from there.
I suspect that we need more protocol-specific properties to be able to talk to various kinds of native protocol peers (other than TCP and UDP: these should already work fine with what we have, I believe). A concrete example: we're hiding stream numbers. In NEAT, we needed to make them configurable though, because we wanted a NEAT client to be able to talk to a native SCTP server, where an application may expect certain type of data to arrive via a certain stream number. I suspect that we may need something similar for a QUIC peer. Should we address this? (I'd say yes) How .. is it a protocol-specific (per-Message) property? (I'd say yes... and perhaps a per-Connection property too, with text explaining that the per-Message one automatically becomes the Connection default unless otherwise specified) What other such things are we missing... what other expectations may e.g. a native QUIC or SCTP application have that we just cannot fulfil with our current system?