Change:
I also added a link to NEATPy in the overview of implementations, and inserted a missing word in interface (a missing "without", must have been a nit)
It might be worth to better align the sections on Message Properties in the API and Implementation draft. Note that e.g. "Final" has more implementation details in the API draft than in the implementation draft.

Discussion:
false This property specifies that a message should be sent and received as <del> a single packet network-layer fragmentation, if possible.  Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError".  When used with transports supporting this functionality and running over IP version 4, the Don't Fragment bit will be set. </del> <ins> a single packet without network-layer fragmentation, if possible. Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError".  When used with transports supporting this functionality and running over IP version 4, the Don't Fragment bit will be set. </ins> 7.6.

can always support this property, but once a Message has been sent into the send buffer of a protocol, only certain protocols may support removing a message.  For example, an implementation cannot <del> cannot remove bytes from a TCP send buffer, while it can remove data from a SCTP send buffer using the partial reliability extension RFC8303.  When there is no standing queue of Messages within the system, and the Protocol Stack does not support the removal of a Message from the stack's send buffer, this property may be ignored. </del> <ins> remove bytes from a TCP send buffer, while it can remove data from a SCTP send buffer using the partial reliability extension RFC8303.  When there is no standing queue of Messages within the system, and the Protocol Stack does not support the removal of a Message from the stack's send buffer, this property may be ignored. </ins> Priority: this represents the ability to prioritize a Message over other Messages.  This can be implemented by the system re-ordering

Safely Replayable: when this is true, this means that the Message can be used by mechanisms that might transfer it multiple times - e.g., as a result of racing multiple transports or as part of TCP <del> Fast Open. </del> <ins> Fast Open.  Also, protocols that do not protect against duplicated messages, such as UDP, can only be used with Messages that are Safely Replayable. </ins> Final: when this is true, this means that a transport connection can be closed immediately after transmission of the message. Corruption Protection Length: when this is set to any value other <del> than -1, it sets the minimum protection in protocols that allow limiting the checksum length (e.g.  UDP-Lite). Singular Transmission: When set, this property limits the message size to the Maximum Message Size Before Fragmentation or Segmentation (see Section 10.1.7 of I-D.ietf-taps-interface). Messages larger than this size generate an error.  Setting this avoids transport-layer segmentation or network-layer fragmentation.  When used with transports running over IP version 4 the Don't Fragment bit will be set to avoid on-path IP fragmentation (RFC8304). </del> <ins> than "Full Coverage", it sets the minimum protection in protocols that allow limiting the checksum length (e.g.  UDP-Lite). Reliable Data Transfer (Message): When true, the property specifies that the Message must be reliably transmitted.  When false, and if unreliable transmission is supported by the underlying protocol, then the Message should be unreliably transmitted.  If the underlying protocol does not support unreliable transmission, the Message should be reliably transmitted. Message Capacity Profile Override: When true, this expresses a wish to override the Generic Connection Property "Capacity Profile" for this Message.  Depending on the value, this can, for example, be implemented by changing the DSCP value of the associated packet (note that the he guidelines in Section 6 of RFC7657 apply; e.g., the DSCP value should not be changed for different packets within a reliable transport protocol session or DCCP connection). No Fragmentation: When set, this property limits the message size to the Maximum Message Size Before Fragmentation or Segmentation (see Section 10.1.7 of I-D.ietf-taps-interface).  Messages larger than this size generate an error.  Setting this avoids transport- layer segmentation or network-layer fragmentation.  When used with transports running over IP version 4 the Don't Fragment bit will be set to avoid on-path IP fragmentation (RFC8304). </ins> 5.1.2.