Change:
false <del> This property specifies that a message should be sent and received as a single packet without network-layer fragmentation, if possible. </del> <ins> This property specifies that a message should be sent and received without network-layer fragmentation, if possible.  It can be used to avoid network layer fragmentation when transport segmentation is prefered. </ins> This only takes effect when the transport uses a network layer that supports this functionality.  When it does take effect, setting this <del> property to true will cause the Don't Fragment bit to be set in the IP header, and attempts to send a message with this property set to a size greater than the transport's current estimate of its maximum packet size ("singularTransmissionMsgMaxLen") will result in a "SendError". </del> <ins> property to true will cause the sender to avoid network-layer source frgementation.  When using IPv4, this will result in the Don't Fragment bit being set in the IP header. Attempts to send a message with this property that result in a size greater than the transport's current estimate of its maximum packet size ("singularTransmissionMsgMaxLen") can result in transport segmentation when permitted, or in a "SendError". Note: noSegmentation should be used when it is desired to only send a message within a single network packet. </ins> 7.1.3.10.

Discussion:
This attempts to set "no segmentation" as the usual case, and this as a corner case - such as would be from a transport that segments at layer 4, but does not fragment at layer 3. This latter case is what is desired to send one message using a sequence of seprate IP packets.
Closing the Frag part of the story
Closing this and merging the Frag parts
Issue: this describes network Fragmentation, but does not really help a user of the transport system know when to request this property. The current text says: This property specifies that a message should be sent and received as a single packet without network-layer fragmentation, if possible. This only takes effect when the transport uses a network layer that supports this functionality. When it does take effect, setting this property to true will cause the Don't Fragment bit to be set in the IP header, and attempts to send a message with this property set to a size greater than the transport's current estimate of its maximum packet size ("singularTransmissionMsgMaxLen") will result in a "SendError". I was guilty of writing one version of this, which I now think has become wrong. I think this should read: This property specifies that a message should be sent and received as without network-layer fragmentation. When running over IPv4, setting this property to true will also cause the Don't Fragment bit to be set in the IP header. It also requests to not perform network-layer source fragmentation. An attempt to send a message with this property set and a size greater than the transport's current estimate of its maximum packet size ("singularTransmissionMsgMaxLen") will result in a "SendError". This function is needed when PMTUD OR PLPMTUD is implemented above the transport system. It might also be used to avoid blackholing when using a path that does not forward fragmented packets.
Linked to
I assume that this is about the Message Property with name "noFragmentation", in section 7.1.3.9: "No Network-Layer Fragmentation". Your proposed update makes three types of changes that I see: 1) it removes "as a single packet" in "should be sent and received as a single packet without network-layer fragmentation". Why? But anyway, I'd be ok with removing it, I don't think this matters.

2) it adds this sentence: "It also requests to not perform network-layer source fragmentation." I think this is good. 3) it removes qualifiers like "This only takes effect when the transport uses a network layer that supports this functionality.", "if possible", and "When it does take effect". Why? What happens, then, when this is requested, but the Transport Services system runs over TCP? I believe that you may have mistaken this for being a Selection Property. I understand that you're concerned with PMTUD and PLPMTUD being able to operate; I suggest that you take a look at the selection properties in section 4.2 to see if you're ok with what they offer, or if something needs to be extended there.
Let's keep "as a single packet" - it adds context. OK. I want us to think on this point. I'm OK with keeping or removing: "This only takes effect when the transport uses a network layer that supports this functionality.", "if possible", because indeed this needs the cooperation of a stack that allows this. .... In mentioning PMTUD, and avoiding blackholes, I wanted examples of how this might be a useful thing for the application to want to use. I'd be even happier to also suggest another reason why this might be needed. ... A few more comments and I'll make a PR;-) Gorry
We agree about 1 and 2. Do we agree about 3? It sounds like we do. But what is it you're asking, or suggesting to change? Confused about 3) :-) Regarding "I'd be even happier to also suggest another reason why this might be needed": I don't understand what's on your mind, but if you can think of useful text, I'd say just propose it in a PR, to be in the right place, and we can discuss it more clearly.
I see, I'll make a PR.
I made two PRs one on seg; one on frag . This deviates a little to the above, but I think it is clean - I'd love review. UDP would allow no Seg; No Frag; - both are the same, UDP does not segment. UDP-O would allow either; No frag (allowing transport seg); or no Seg.

QUIC, TCP would always do no frag; -- does no Seg is not possible? SCTP would do no Frag (note it would still send frags, but avoid their usage).