Original text:
other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties <del> except "Connection Priority", see conn-priority.  Like all other </del>  Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group.  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. 8.1.2.1. The Message Framer object can be added to one or more Preconnections <del> to run on top of transport protocols.  Multiple Framers may be added. If multiple Framers are added, the last one added runs first when framing outbound messages, and last when parsing inbound data. </del>  The following example adds a basic HTTP Message Framer to a Preconnection:  8.1.2.2. When sending Messages, applications can add Framer-specific key/value

Reviewer comments:
How do framers behave in connection groups? I.e. do all connections share one framer object or does the framer object get duplicated when a connection gets cloned? If it does get duplicated, does it keep its current state? This might mostly be an implementation detail but I think it should be mentioned in section 6.4 of API.
Interim: same type of framer is plausible default (but new instances), but in general a framer should be per connection. State is not shared across connections. Bigger problem: framers are added to preconnections, not connections, so how is this done with cloning? (perhaps: add list of framers as parameter added to the clone call)
I've thought about it, and Idon't think we actually have a bigger problem here: On an initiated Connection/ConnectionGroup, the provenance of the Framers is Preconnection.AddFramer() -> Preconnection.Initiate(). On a Listener, the provenance of the Framers is Preconnection.AddFramer() -> Preconnection.Listen() -> Listener.Clone(). In a Rendezvous situation, there is (unless I'm missing something) always a Preconnection from which a Framer can ultimately be inherited.
In §8.1.2 ¶3, the doc says: but this doesn't seem to be conceptually compatible with the text at the top of §8.1.2.1, which says: I think the way most developers would think about this is as a pipeline: you feed data into the top-level framer with Send, which then percolates downward through the pipeline to the bottom-level framer, which then sends it to the transport.
I think this should be easy to address, by rephrasing: as: ... BUT "call each other" is surely a terrible way to put this, and there must be a way to say this cleanly and neatly, in line with how the code really goes. THIS, I suspect, is a very simple thing for NAME to do, and hence I assigned it to him.

Revised text:
other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties  <ins> except "Connection Priority" (see conn-priority) .  Like all other </ins> Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group. <ins> The stack of Message Framers associated with a Connection are also copied to the cloned Connection when calling Clone.  In other words, a cloned Connection has the same stack of Message Framers as the Connection from which they are Cloned, but these Framers may internally maintain per-Connection state. </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. 8.1.2.1. The Message Framer object can be added to one or more Preconnections  <ins> to run on top of transport protocols.  Multiple Framers may be added to a preconnection; in this case, the Framers operate as a framing stack, i.e. the last one added runs first when framing outbound messages, and last when parsing inbound data. </ins> The following example adds a basic HTTP Message Framer to a Preconnection: <ins> Since Message Framers pass from Preconnection to Listener or Connection, addition of Framers must happen before any operation that may result in the creation of a Connection. </ins> 8.1.2.2. When sending Messages, applications can add Framer-specific key/value