Change:
4.1.1.2. <del> If a client has multiple network interfaces available to it, e.g., a mobile client with both Wi-Fi and Cellular connectivity, it can attempt a connection over any of the interfaces.  This represents a branch point in the connection establishment.  Similar to a derived endpoint, the interfaces should be ranked based on preference, system policy, and performance.  Attempts should be started on one interface, and then on other interfaces successively after delays based on expected round-trip-time or other available metrics. </del> <ins> If a client has multiple network paths available to it, e.g., a mobile client with intefaces for both Wi-Fi and Cellular connectivity, it can attempt a connection over any of the paths. This represents a branch point in the connection establishment. Similar to a derived endpoint, the paths should be ranked based on preference, system policy, and performance.  Attempts should be started on one path (e.g., a specific interface), and then successively on other paths (or interfaces) after delays based on expected path round-trip-time or other available metrics. </ins> This same approach applies to any situation in which the client is <del> aware of multiple links or views of the network.  Multiple Paths, each with a coherent set of addresses, routes, DNS server, and more, may share a single interface.  A path may also represent a virtual interface service such as a Virtual Private Network (VPN). </del> <ins> aware of multiple links or views of the network.  A single interface may be shared by multiple network paths, each with a coherent set of addresses, routes, DNS server, and more.  A path may also represent a virtual interface service such as a Virtual Private Network (VPN). </ins> The list of available paths should be constrained by any requirements <del> or prohibitions the application sets, as well as system policy. </del> <ins> the application sets, as well as by the system policy. </ins> 4.1.1.3.

Discussion:
After reading , I reviewed the latest text. I'm unsure I want to make changes to Arch/API: I see path as "network path", that is the set of hops through which the packet is forwarded (the local interface being the first local hop, and PvD information/PMTU/etc relating to something non-local). This changes the examples using interface to align with this.
Impl draft, section 4.1.2: "Each node will be summarized by a tuple of three elements: Endpoint, Path, and Protocol. The above example can now be written more succinctly as: 1 [URL, Any, TCP] 1.1 [URL, Wi-Fi, TCP] 1.1.1 [192.0.2.1:80, Wi-Fi, TCP] 1.2 [URL, LTE, TCP] 1.2.1 [192.0.2.1:80, LTE, TCP] 1.2.2 [2001:DB8::1.80, LTE, TCP]" looking at the example I would not call this "Endpoint, Path, and Protocol" but "Remote Endpoint, Local Endpoint or interface, and Protocol". Not sure we have defined the term Path well but I would consider a path to consists of both the local and remote endpoint plus optionally maybe even some more information about the path characteristics that might be known for this endpoint pair.
Yeah, it is "remote endpoint", "interface/local endpoint", and "protocol".
note that the wording needs to be fix at least in a few more places, so whoever puts the PR in should probably reach for the word path and ensure it's used correctly...
especially 4.1.3.2. (Alternate Paths) wouldn't fit that well anymore and would probably need some rewriting...