Original text:
example, if reliable delivery was requested for a Message handed over before calling Close, the Closed Event will signify that this Message has indeed been delivered.  If the Remote Endpoint still has data to <del> send, it cannot be received after this call. </del>  The Closed Event informs the application that the Remote Endpoint has closed the Connection.  There is no guarantee that a remote Close will indeed be signaled. <del> Abort terminates a Connection without delivering any remaining data: </del>  A ConnectionError informs the application that: 1) data could not be delivered to the peer after a timeout, or 2) the Connection has been

Reviewer comments:
Should taps-interface provide a way to close a connection group? I don't see an obvious way to close an HTTP/2 or QUIC connection just using connection-level commands. You could make TAPS automatically close a connection if all user streams are closed, but that's... not great?
What's the problem with closing a connection (I presume you mean the underlying transport's one, not the one exposed by TAPS) once all user streams (i.e., grouped TAPS Connections) are closed? I think this would obviously happen. If I, as a user, want to avoid delay for connection establishment and tear-down, I'm not closing my Connection... Else, closing a group containing multiple open Connections in one go would be a matter of issuing "Close" for all of them... e.g., by checking the Connection's group number, in a loop. We could spec that as part of the API, but it doesn't seem to be extremely useful to me, as this function could very easily be written on top of the TAPS API.
This works for me, Gorry
Alternative discussed: make ConnectionGroup an explicit object (as opposed to just a []Connection), and add (at least) an AbortGroup call on it. Another option: add AbortGroup to a Connection, which aborts all connections in the group. Discussion at December interim leans toward the second: don't create a new object for only one operation.
Also, make sure to be clear that Abort() does NOT close all entangled Connections. (same thing for Close())

Revised text:
example, if reliable delivery was requested for a Message handed over before calling Close, the Closed Event will signify that this Message has indeed been delivered.  If the Remote Endpoint still has data to  <ins> send, it cannot be received after this call.  This action does not affect any other Connection that is entangled with this one in a Connection Group. </ins> The Closed Event informs the application that the Remote Endpoint has closed the Connection.  There is no guarantee that a remote Close will indeed be signaled.  <ins> Abort terminates a Connection without delivering any remaining data. This action does not affect any other Connection that is entangled with this one in a Connection Group. AbortGroup terminates a Connection and also terminates any other Connections that are entangled with this one in a Connection Group. For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; aborting the entire group would close the underlying session.  See also groups. </ins> A ConnectionError informs the application that: 1) data could not be delivered to the peer after a timeout, or 2) the Connection has been