Change:
The rest of this section will use a notation scheme to represent this tree.  The parent (or trunk) node of the tree will be represented by <del> a single integer, such as "1".  Each child of that node will have an integer that identifies it, from 1 to the number of children.  That 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: endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as: </del> <ins> a single integer, such as "1". ("1" is used assuming that this is the first connection made by the system; future connections created by the application would allocate numbers in an increasing manner.) Each child of that node will have an integer that identifies it, from 1 to the number of children.  That 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: endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as: </ins> When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer

Discussion:
I'm having difficult parsing "At this point, any constraints or requirements the application may have on the connection are available from pre-establishment." I'm not even sure what meaning is intended. Available? To what and for what? Is this really a forest? I.e., is a possible when, for instance, you have a choice of two hostnames? If so, there should be an example illustrating that. The last example in the section should be augmented to show multiple hostnames as described by the preceding paragraph. Additionally, I think stating that there is a clear/natural dependency relationship between branching operations such that later operations depend on earlier decisions could simplify and clarify the justification for the suggested order of operations. "Scavenger" implies LEDBAT to me: it will take whatever is currently not being used but will defer to everything else. I'm not sure that notion aligns with the preference described. Is the intent of: that a protocol higher in the stack (or a framer?) could use 0-RTT even if the application doesn't want 0-RTT? Are there any security or privacy implications to this? Should there be a mechanism to disable this entirely? I do not understand the syntax employed here. Is in: a global object or something? It appears to be generating a Start event with the Connection object to the system, but isn't the framer the receiver of such an event? (Nit: isn't Event<> with angle brackets the syntax here?) doesn't seem quite right. Protocols possess a property of application-layer data unit, usually as an intrinsic property that is a direct consequence of the protocol design. They don't really define it so much as end up with it. Maybe this is too much of a nit, but it reads weirdly. The use of "unconnected" (or "connectionless") directly adjacent to the phrase "UDP connections" is driving me batty. I understand that the TAPS interface provides only a Connection object, but we should not ever use lowercase-c "connection" to refer to UDP, and be clear when we mean the uppercase-C "Connection" object in relation to an underlying UDP transport.

I rust just read this as "The Implementation now has all constrains it needs to know for attempting to establish a connection in the form of Preconnection parameters (endpoints, security parameters and transport properties) and can now continue." I would imagine that if 0-RTT is set to prohibit that applies to the entire stack (including framers). This is a bit confusing, but basically, as far as I understand, there is the MessageFramer which is part of the TAPS Implementation (this creates the events and has the methods MakeConnectionReady, MakeConnectionClosed etc.) and there is the framer implementation (which is the part the users of the TAPS implementation write themselves, this receives the events and then calls the methods on the MessageFramer). It might be good to find another term for MessageFramer to make that difference more clear.
WFM