Change:
state between CoAP client and server, verify aliveness of the client, or force a client to demonstrate reachability at its claimed network address.  The same functionality can be provided by echoing freshness <del> tokens in CoAP payloads, but this only works for methods and response codes defined to have a payload.  The Echo option provides a convention to transfer freshness tokens that works for all methods and response codes. </del> <ins> indicators in CoAP payloads, but this only works for methods and response codes defined to have a payload.  The Echo option provides a convention to transfer freshness indicators that works for all methods and response codes. </ins> 1.2.

Discussion:
With those, any open issues I'm aware of except the single words from and the larger discussion or are resolved from my PoV.
s/freshness tokens/freshness indicators/ : Amended by a proposed term to solve the remaining point in -- feel free to change to something different, it's just a shortcut suggestion.
"freshness indicators": OK with John, 0.00 OK, endpoints with security associations OK
"Block-Wise" vs. "block-wise" vs. "blockwise" "Token" vs. "Token" I think it should be Token. "freshness tokens" I think we should rewrite "freshness tokens" to that the word "token" is only used for the CoAP Token.
The Token and block-wise have been addressed in your f9abfe02595c19a6f5d37f88a29cfafa59a3254a. Any candidates for "freshness tokens" replacement? "freshness indicators" maybe?
I tried to add security considerations for token reuse to the PR. Please review, this is not trivial. Token reuse for DTLS seem hard if not impossible to do securely. I don't find Token reuse with DTLS possible to do securely..... am I missing something? Token reuse for TLS without Observer and without Groups communication seems quite easy. Do we need to say something about Group communication? Do we need to say something about stateless tokens? I think the current requirements on integrity protection and replay protection protection in the stateless draft should be enough.
I think John refers to e49ff36
Taken care of in the version -07
While not designed for that, the Echo option can be abused as mechanism like HTTP's Cookie (especially when preemptive Echo values are passed around), and I'm pretty sure we don't want that. We should at least point that out somewhere, and say that servers MUST NOT abuse it (however to phrase that -- "use Echo to correlate requests for other purposes than showing frechness and reachability"?). For actual mitigation, we could recommend (or even demand?) that clients only send preemptive Echo values on the same endpoint (5-tuple) on which they were received -- so that if their address changes, no Echo value will leak identity.

To still allow Echo in OSCORE groupcom (new server asks for Echo, client repeats it in next multicast, others ignore it), we could limit that mitigation to unauthenticated use cases (as the client has a known persistable identity with OSCORE anyway).
Yes, this should definitely be a privacy consideration.
I wrote some initial text for the privacy consideration regarding this. Please revieew, modify and add things. Should we have any considerations for group OSCORE? of should we let draft-dijk-core-groupcomm-bis and group OSCORE discuss that. Echo Request is hopefully published before them.
I think John refers to this commit: bcceb8a
I'm almost happy with it, the last word I'm unhappy with is being addressed in an upcoming commit that closes it by drawing on a solution to the "the spec does not say anything regarding taking echo from (no-security, DTLS, [...]) and using it in (no-security, DTLS, [...])" comment,