Change:
Abort terminates a Connection without delivering any remaining data: A ConnectionError informs the application that: 1) data could not be <del> delivered after a timeout, or 2) the other side has aborted the Connection.  There is no guarantee that an Abort will indeed be signaled. </del> <ins> delivered to the peer after a timeout, or 2) the Connection has been aborted (e.g., because the peer has called Abort).  There is no guarantee that an Abort will indeed be signaled. </ins> 10.

Discussion:
, , , . Partially addresses . A few comments: : Kyle's comment addressed ("Connection Properties can be set on Preconnections" fixed to "Connection Properties can be set on Preconnections and Connections") : I don't think the sentence explaining what an application could do upon an establisment error is necessary. I removed it, and now the text should be clearer. : All Connection Properties but "Priority (Connection)" are entangled. This is now clearly stated, not mentioned as an example. : Great catch. I now replaced this with an example that talks about ordering (clearly, requiring ordering from UDP will have to fail). : Reworded all the bits you point out, hopefully it's all clearer now. : first, there was a broken sentence, which seemed to miss "will not occur", so I added this. Then, I removed the last sentence which had the contradictory "ConnectionError<> can occur after Closed<>, ..." statement.
contradicts itself in one paragraph: It seems like Closed<> can and should be it: the stack should refuse any further interaction with userspace for this connection after that point.
says: The transport system can't ensure that: it can ensure that either the message is delivered before clean shutdown or the connection will be broken without a clean shutdown. Later, it says: "Deliver" in the context of transports is a term of art that means "the stack handed the data over to the application". The local endpoint has no way of knowing when or if this has happened: the remote endpoint will happily ACK packets until the rxbuf is full, without delivering a single byte of data to the application. What is the actual condition under which this will fire? I think this wants to be more general, because this will happen (e.g., in TCP) even if a MITM sends a RST. Maybe just "the connection is otherwise broken".
Why? Even an unreliable connection can block forever if congestion control is in place. Maybe a better illustration is: what should the TTL on a UDP message be? Is there a maximum? If so, how do you know what it is or specify it? Maybe a better example is warranted here.
"Entangled" appears eight times in the doc and its effect is never precisely defined.

The doc should specify in an easily-consumable format (e.g., a table, but not necessarily a table) exactly which properties are shared between cloned connections and which aren't.
I am having difficult parsing:
: "Although Connection Properties (see Section 7.1) can be set during pre-establishment, they may be changed later." Four sentences later: "Connection Properties can be set on Preconnections"
Unrelated, but about the same text: I notice something weird here, regarding compilation. Looking at https://ietf-URL I see: ... which is broken at the end. However, looking at URL I see: They are used to inform decisions made during establishment and to fine-tune the established connection. The behavior of the selected protocol stack(s) when sending Messages is controlled by Message Properties (see {{message-props}}). ... which is much better. Since the last manual commit is 2 days ago, this must be a strange compilation mistake.
PR has addressed Kyle's point - so this is now about something else. Please see my comment above.
The file is the correct copy. We can close this.