Change:
Make clearer what "Priority is not entangled" means, following . Also added a note that Clone() may result in on-the-wire signaling.
Section 11.1.3 of the API says about Priority: "As noted in Section 6.4, this property is not entangled when Connections are cloned." Not sure what this means. I though when you clone a connection you would actually take the priority of the cloned connection but then you can change it independently for each connection in a group. Or what's the priority after cloning? Back to the default of 100? We should say this explicitly. Or maybe you even want to provide the priority while cloning? Actually looking at this now again, I think we would need to specify cloning a bit better anyway. I assume that calling clone() on a multiplexing capable connection would create a new stream; in case of quic is would only create local state but no on-the-wire singling. However if you call clone on a TCP connection, is that basically an initial() call that triggers the TCP handshake? We should say this explicitly.
I'd say it's exactly as you thought: When you clone a Connection, all Properties are copied (including the Priority), but then they are not entangled: If you change the Priority on the cloned Connection, the Priority on the original Connection stays as it was. If Priority was entangled, then it would change on both Connections if you change it on one of them. But yes, perhaps this is confusing and the text should be more explicit. The part on specifying cloning better: There's text on this in the Implementation draft on what happens with Clone() for each protocol. But maybe we can say in the API document that Clone() might trigger on-the-wire signaling or it might not, depending on the protocol.
Yes, both additions/clarification would be good.
LGTM - and thanks for adding this clarification!Thank you for the clarifications!

Discussion:
Connections adds a third Connection to the Connection Group, and so on.  Connections in a Connection Group generally share Connection Properties.  However, there may be exceptions, such as "Priority <del> (Connection)", see conn-priority. </del> <ins> (Connection)", see conn-priority.  Like all other Properties, Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Priority on one Connection does not change it on the other Connections in the same Connection Group. </ins> In addition, incoming entangled Connections can be received by creating a Listener on an existing connection:

not only inside endpoints but also across the end-to-end Internet path. <ins> Note that calling Clone() may result in on-the-wire signaling, e.g., to open a new connection, depending on the underlying Protocol Stack. </ins> If the underlying Protocol Stack does not support cloning, or cannot create a new stream on the given Connection, then attempts to clone a Connection will result in a CloneError:

inverse priority of this Connection relative to other Connections in the same Connection Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not <del> entangled when Connections are cloned. </del> <ins> entangled when Connections are cloned, i.e., changing the Priority on one Connection in a Connection Group does not change it on the other Connections in the same Connection Group. </ins> 11.1.4.