Original text:
Stop action is performed on the Listener object. The ConnectionReceived Event occurs when a Remote Endpoint has <del> established a transport-layer connection to this Listener (for Connection-oriented transport protocols), or when the first Message has been received from the Remote Endpoint (for Connectionless protocols), causing a new Connection to be created.  The resulting Connection is contained within the ConnectionReceived Event, and is ready to use as soon as it is passed to the application via the event. </del>  If the caller wants to rate-limit the number of inbound Connections that will be delivered, it can set a cap using Calling Clone on a Connection yields a Connection Group containing two Connections: the parent Connection on which Clone was called, and a resulting cloned Connection.  The new Connection is actively <del> openend, and it will send a Ready Event or an EstablishmentError Event.  Calling Clone on any of these Connections adds another Connection to the Connection Group.  Connections in a Connection Group share all Connection Properties except "connPriority" (see conn-priority), and these Connection Properties are entangled: Changing one of the Connection Properties on one Connection in the Connection Group automatically changes the Connection Property for all others.  For example, changing "connTimeout" (see conn-timeout) on one Connection in a Connection Group will automatically make the same change to this Connection Property for all other Connections in the Connection Group.  Like all other Properties, "connPriority" is copied to the new Connection when calling Clone(), but in this case, a later change to the "connPriority" on one Connection does not change it on the other Connections in the same Connection Group. </del>  The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying

Reviewer comments:
I added text to ConnectionReceived about this. I didn't additionally explicitly state this in the text about clone to avoid complicating things - since similarly, the text describing Initiate() doesn't talk about ConnectionReceived.
If is called, is an unsolicited event generated at the peer? I assume so, but can't find it documented.
Do you want this to happen specifically upon calling clone(), or is it good enough if it happens upon the first arrival of data on the new Connection? The latter could be specified (and I'd have to check if it isn't already). However, in the first case, we could specify that this should happen if possible, but I don't think it's a behaviour that can be promised. For a multi-streaming protocol, URL() just means "from now on, we have a new Connection, for which we're going to use a new stream" - so I don't think that anything's immediately going to happen on the wire just due to clone() in this case.
I'd expect a event to be delivered before an event indicating arrival of data on the new connection. That could be immediately before, if there's no explicit on-the-wire signalling that the new connection has been created.
Ah, ok! I agree it should happen as you describe it, and I'll take care of this: I'll check if this is already covered (and if so, if the text should be more explicit about it). If it isn't covered, I'll add text to state this.

Revised text:
Stop action is performed on the Listener object. The ConnectionReceived Event occurs when a Remote Endpoint has  <ins> established or cloned (e.g., by creating a new stream in a multi- stream transport; see groups) a transport-layer connection to this Listener (for Connection-oriented transport protocols), or when the first Message has been received from the Remote Endpoint (for Connectionless protocols or streams of a multi-streaming transport), causing a new Connection to be created.  The resulting Connection is contained within the ConnectionReceived Event, and is ready to use as soon as it is passed to the application via the event. </ins> If the caller wants to rate-limit the number of inbound Connections that will be delivered, it can set a cap using Calling Clone on a Connection yields a Connection Group containing two Connections: the parent Connection on which Clone was called, and a resulting cloned Connection.  The new Connection is actively  <ins> openend, and it will locally send a Ready Event or an EstablishmentError Event.  Calling Clone on any of these Connections adds another Connection to the Connection Group.  Connections in a Connection Group share all Connection Properties except "connPriority" (see conn-priority), and these Connection Properties are entangled: Changing one of the Connection Properties on one Connection in the Connection Group automatically changes the Connection Property for all others.  For example, changing "connTimeout" (see conn-timeout) on one Connection in a Connection Group will automatically make the same change to this Connection Property for all other Connections in the Connection Group.  Like all other Properties, "connPriority" is copied to the new Connection when calling Clone(), but in this case, a later change to the "connPriority" on one Connection does not change it on the other Connections in the same Connection Group. </ins> The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying