Change:
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...

Discussion:
The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect, <del> using the system's current default interface or path, and starting a TCP handshake to establish a stream to the specified IP address. However, each step may also differ depending on the requirements of the connection: if the endpoint is defined as a hostname and port, then there may be multiple resolved addresses that are available; there may also be multiple interfaces or paths available, other than the default system interface; and some protocols may not need any transport handshake to be considered "established" (such as UDP), while other connections may utilize layered protocol handshakes, such as TLS over TCP. </del> <ins> using the system's current default path (i.e., using the default interface), and starting a TCP handshake to establish a stream to the specified IP address.  However, each step may also differ depending on the requirements of the connection: if the endpoint is defined as a hostname and port, then there may be multiple resolved addresses that are available; there may also be multiple paths available, (in this case using an interface other than the default system interface); and some protocols may not need any transport handshake to be considered "established" (such as UDP), while other connections may utilize layered protocol handshakes, such as TLS over TCP. </ins> Whenever an implementation has multiple options for connection establishment, it can view the set of all individual connection

document. Each leaf node of the tree represents a single, coherent connection <del> attempt, with an endpoint, a path, and a set of protocols that can directly negotiate and send data on the network.  Each node in the tree that is not a leaf represents a connection attempt that is either underspecified, or else includes multiple distinct options. </del> <ins> attempt, with an endpoint, a network path, and a set of protocols that can directly negotiate and send data on the network.  Each node in the tree that is not a leaf represents a connection attempt that is either underspecified, or else includes multiple distinct options. </ins> For example, when connecting on an IP network, a connection attempt to a hostname and port is underspecified, because the connection attempt requires a resolved IP address as its Remote Endpoint.  In

hostname is a parent node, with child nodes for each IP address. Similarly, an implementation that is allowed to connect using multiple interfaces will have a parent node of the tree for the <del> decision between the paths, with a branch for each interface. </del> <ins> decision between the network paths, with a branch for each interface. </ins> The example aggregate connection attempt above can be drawn as a tree by grouping the addresses resolved on the same interface into

child node will be uniquely identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: <del> endpoint, path, and protocol.  The above example can now be written more succinctly as: </del> <ins> endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as: </ins> When an implementation views this aggregate set of connection attempts as a single connection establishment, it only will use one

If a connection originally targets a single endpoint, there may be multiple endpoints of different types that can be derived from the <del> original.  The connection library creates an ordered list of the derived endpoints according to application preference, system policy and expected performance. </del> <ins> original.  This creates an ordered list of the derived endpoints according to application preference, system policy and expected performance. </ins> DNS hostname-to-address resolution is the most common method of endpoint derivation.  When trying to connect to a hostname endpoint

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.