Original text:
where messageData is the data object to send. <del> The optional messageContext parameter supports per-message properties and is described in message-props.  It can be used to identify send events (see send-events) related to a specific message or to inspect meta-data related to the message sent (see msg-ctx). </del>  The optional endOfMessage parameter supports partial sending and is described in send-partial. Message (i.e., whether it has actually been transmitted, moved into a buffer on the network interface, moved into a kernel buffer, and so on) when the Sent Event occurs is implementation-specific.  The Sent <del> Event contains an implementation-specific reference to the Message to which it applies. </del>  Sent Events allow an application to obtain an understanding of the amount of buffering it creates.  That is, if an application calls the completion; i.e. when the Message was not sent before its Lifetime (see msg-lifetime) expired.  This is separate from SendError, as it is an expected behavior for partially reliable transports.  The <del> Expired Event contains an implementation-specific reference to the Message to which it applies. </del>  7.3.3. condition: an attempt to send a Message which is too large for the system and Protocol Stack to handle, some failure of the underlying Protocol Stack, or a set of Message Properties not consistent with <del> the Connection's transport properties.  The SendError contains an implementation-specific reference to the Message to which it applies. </del>  7.4. Message Properties can be set and queried using the Message Context: To get or set Message Properties, the optional scope parameter is <del> left empty, for framing meta-data, the framer is passed. </del>  For MessageContexts returned by send events (see send-events) and receive events (see receive-events), the application can query

Reviewer comments:
Tentatively answering my own questions in : Removed the messageContext here because the RendezvousError does not necessarily relate to a specific sent Message. If it does, the "reason" parameter can point to that message and/or a messageContext. The beginning of Section 7 actually already said that this IS the messageContext. I removed the word "implementation-specific" because to me this word made it sound like this reference can't be the messageContext. Split into two sentences and changed the second sentence to active voice. Also, I slightly reworded the beginning of Section 7, which is now a bit clearer in my opinion.
When reading the current API draft, I found three minor issues related to Message Contexts. The RendezvousError (Section 6.3) includes a messageContext (which is even required), but neither the InitiateError nor the ListenError include one. Why? Should this messageContext at least be optional?In Section 7.3, it says "The Sent Event contains an implementation-specific reference to the Message to which it applies." - Is this in addition to the messageContext? If yes, why do we need both?In Section 9, it says "To get or set Message Properties, the optional scope parameter is left empty, for framing meta-data, the framer is passed." - I think this sentence is a bit hard to parse and it wasn't immediately obvious to me what kind of framing meta-data this refers to. Perhaps this refers to Section 10.2, so I think it's worth adding a reference to that section here. Also, I suggest turning this into two sentences, with the sentence on framing meta-data specifying that this is per-Message metadata to be used by the framer.
Thanks a lot for doing this! It clears things up nicely, I think.

Revised text:
where messageData is the data object to send.  <ins> The optional messageContext parameter allows adding Message Properties as described in message-props.  Moreover, the messageContext can be used to identify Send Events related to a specific Message (see send-events) or to inspect meta-data related to the Message sent (see msg-ctx). </ins> The optional endOfMessage parameter supports partial sending and is described in send-partial. Message (i.e., whether it has actually been transmitted, moved into a buffer on the network interface, moved into a kernel buffer, and so on) when the Sent Event occurs is implementation-specific.  The Sent  <ins> Event contains a reference to the Message to which it applies. </ins> Sent Events allow an application to obtain an understanding of the amount of buffering it creates.  That is, if an application calls the completion; i.e. when the Message was not sent before its Lifetime (see msg-lifetime) expired.  This is separate from SendError, as it is an expected behavior for partially reliable transports.  The  <ins> Expired Event contains a reference to the Message to which it applies. </ins> 7.3.3. condition: an attempt to send a Message which is too large for the system and Protocol Stack to handle, some failure of the underlying Protocol Stack, or a set of Message Properties not consistent with  <ins> the Connection's transport properties.  The SendError contains a reference to the Message to which it applies. </ins> 7.4. Message Properties can be set and queried using the Message Context: To get or set Message Properties, the optional scope parameter is  <ins> left empty.  To get or set meta-data for a Framer, the application has to pass a reference to this Framer as the scope parameter. </ins> For MessageContexts returned by send events (see send-events) and receive events (see receive-events), the application can query