Change:
4.2.3. The Transport Services architecture defines a mechanism that allows <del> applications to easily use different network paths and Protocol Stacks.  In some cases, changing which Protocol Stacks or network paths are used will require updating the preferences expressed by the application that uses the Transport Services system.  For example, an application can 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 by racing multiple candidate Protocol Stacks during connection establishment.  This functionality in the API can be a powerful driver of new protocol adoption, but needs to be constrained carefully to avoid unexpected behavior that can lead to functional or security problems. </del> <ins> applications to easily make use of various network paths and Protocol Stacks without requiring major changes in application logic.  In some cases, changing which Protocol Stacks or network paths are used will require updating the preferences expressed by the application that uses the Transport Services system.  For example, an application can 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 by racing multiple candidate Protocol Stacks during connection establishment. This functionality in the API can be a powerful driver of new protocol adoption, but needs to be constrained carefully to avoid unexpected behavior that can lead to functional or security problems. </ins> If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent".

Discussion:
In the architecture document, I think Section 4.2.3 Protocol Stack Equivalence could be misinterpreted to mean connection migration, i.e., changing network paths or protocol stacks during the lifetime of a single Connection. "The Transport Services architecture defines a mechanism that allows applications to easily use different network paths and Protocol Stacks. In some cases, changing which Protocol Stacks or network paths are used will require updating the preferences expressed by the application that uses the Transport Services system." It says "use different network paths and Protocol Stacks" and talks about changing these, but it does not say in what context or over what timeframe. Maybe here it would help to say something like "The Transport Services architecture defines a mechanism that allows applications to easily use different network paths and Protocol Stacks for their Connections or start using new protocols as they get implemented, without requiring major changes to the applications".
Agreed, sounds good
I don't think there's any particular reason a future transport shouldn't renegotiate paths and stack components on the fly (but then again I think the future of the Internet will see endpoints using TLS/TCP/IPv4 only to establish cryptographic and routing state, then dynamically negotiating connectivity beyond that, i.e. "legacy Internet as a bootstrap protocol alone" so my opinion should probably be regarded as a minority one and best ignored. :) )
+1 to Brian but I guess I was sharing an office with him for too long ;-)
So... This is a case where I wouldn't wish to speculate. It was controversial in the lead-up to TAPS for various reasons, and I'd really encourage we do not start thinking in this RFC about how that may turn in future. I do like Theresa's new para above. I would argue not to add more.
Thanks for fixing!