Original text:
is not entangled: Changing Priority on one Connection does not change it on the other Connections in the same Connection Group. <del> In addition, incoming entangled Connections can be received by creating a Listener on an existing connection: ListenClone() creates a Listener that listens on the same LocalEndpoint as the one the cloned Connection is using.  Any new Connection received by this Listener will be entangled with the cloned Connection.  Changing one of the Connection Properties on one Connection in the group changes it for all others.  Message Properties, however, are not entangled.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Connection Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg-lifetime) of a Message will only affect a single Message on a single Connection, entangled or not. </del>  If the underlying protocol supports multi-streaming, it is natural to use this functionality to implement Clone.  In that case, entangled

Reviewer comments:
Proposal: replace this with a way to query for a connection what the other connections in a group are (which will only happen passively for multi streamed protocols today).
Implemented ; NAME does this work?
I'm merging this now so I can proceed with re-structuring. It reflects what we discussed at the interim, so I don't think there should be more concerns.
See the discussion in PR . I think this is best dealt with by merging PR after a small fix, then doing a separate PR to address this. IMO the easiest way to do this is to allow to query a group number (a simple integer). Without grouping, every new Connection simply gets a new number. Having the same group number as any previous Connection(s) indicates group membership. This is how we did it in NEAT too. If people agree with this, I can take care of this.
I remember the discussion in NEAT, to me it seems a good way to resolve the issue.
PR now resolves this differently. It doesn't matter much, IMO the method in this PR also works fine.
I merged PR , which closes this issue.
Should ListenClone() fail for non-multiplexed transports How to specify if a top-level listener can accept cloned (multiplexed) streams Should ListenClone() be called ListenForClone()...?
Just a note to say that issue waits for this issue to be addressed.
Rename function Trying to do this without a multiplexing transport should fail
ping: issue is waiting for this...
Currently the "Clone" part of, e.g., TCP (section 10.1) only says: "Calling Clone on a TCP Connection creates a new Connection with equivalent parameters. The two Connections are otherwise independent." This text should reflect that equivalent behavior must be maintained upon later Connection configuration calls. And, there should be more text in general on cloning (see issue ).
This text must refer to a new "do I want a Connection that supports initiate followed by listen?" property. This property will be added to address - so I'll address this issue when the PR addressing has landed.
I'm ok with this modulo one suggested change

Revised text:
is not entangled: Changing Priority on one Connection does not change it on the other Connections in the same Connection Group.  <ins> It is also possible to check which Connections belong to the same Connection Group.  Calling GroupedConnections() on a specific Connection returns a set of all Connections in the same group. Connections will be in the same group if the application previously called Clone.  Passive Connections can also be added to the same group - e.g., when a Listener receives a new Connection that is just a new stream of an already active multi-streaming protocol instance. Changing one of the Connection Properties on one Connection in the group changes it for all others.  Message Properties, however, are not entangled.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Connection Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- lifetime) of a Message will only affect a single Message on a single Connection, entangled or not. </ins> If the underlying protocol supports multi-streaming, it is natural to use this functionality to implement Clone.  In that case, entangled