Original text:
4.1.1. This is an example of how an application might listen for incoming <del> Connections using the Transport Services Interface, receive a </del>  request, and send a response. 4.1.2. <del> This is an example of how an application might connect to a remote application using the Transport Services Interface, send a request, and receive a response. </del>  4.1.3. the remote peer.  This boolean becomes false when "Timeout for aborting Connection" (see conn-timeout) is used.  7.3. During the lifetime of a connection there are events that can occur

Reviewer comments:
I found the relationship between streams and connections to be extremely murky throughout the draft, and left it not really sure how I would control a streamed transport. Section 6.4 hints suggests that opening additional streams is an alternative implementation of Clone() for transports that can do so. Does this imply that if the peer stream limit does not allow new streams, the transport should open a connection instead? How does SetNewConnectionLimit() in Sec 6.2 relate to streamed transport -- are there two levels of listener: a stream listener and a connection listener? How would opening "stream listeners" relate to the maximum number of streams the peer could open (i.e. do I have to call listen() 8 times to allow the client to open 8 streams)? Or are there no stream listeners and these "connections" just sort of appear? Skimming the -impl draft, I can see there's some text here but it is not fitting together for me. There are at least three streamed transports and it would be helpful to explain how the API conceptualizes this, perhaps in a new section.
To clarify, Listen() is called once and keeps receiving streams within the NewConnectionLimit. The main thing to clarify is how the NewConnectionLimit applies to streams of a multiplexed transport. We could look at having a limit of connections per endpoint in a group from a listener.
Add a property to section 7.1.
Also make sure to have an early section being very explicit about the overall interaction model.
In section 4.1, we could add an example for explicit group management via clone, etc.
Sigh, I will never self-assign an issue again before its discussion :-) but it's ok... I'll do it

Revised text:
4.1.1. This is an example of how an application might listen for incoming  <ins> Connections using the Transport Services Interface, and receive a </ins> request, and send a response. 4.1.2.  <ins> This is an example of how an application might open two Connections to a remote application using the Transport Services Interface, and send a request as well as receive a response on each of them. </ins> 4.1.3. the remote peer.  This boolean becomes false when "Timeout for aborting Connection" (see conn-timeout) is used. <ins> 7.2.4. groupConnLimit Numeric (with special value "Unlimited") Unlimited This property controls the number of Connections that may arrive from a peer as new members of the Connection's group.  Similar to SetNewConnectionLimit(), this limits the number of ConnectionReceived Events that will occur, but constrained to the group of the Connection associated with this property.  In case of a multi- streaming transport, this takes the role of a limit on the number of allowed streams. </ins> 7.3. During the lifetime of a connection there are events that can occur