Original text:
3.  A client that supports this extension and at least one flag extension SHALL send this extension with the flags field having bits set only for those extensions that it intends to set.  It MUST NOT send this extension with a length of zero. <del> A server that supports this extension and also supports at least one of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it supports with the flags declared by the client.  The intersection operation may be implemented as a bitwise AND.  The server may need to send multiple tls_flags extensions, up to one in each of the four response messages that may carry extensions: ServerHello (SH), EncryptedExtensions (EE), Certificate (CT), and HelloRetryRequest (HRR).  It is up to the document for the specific feature to determine which of these should be used to acknowledge support. A server MUST NOT indicate support for any flag-type feature not previously indicated by the client in the ClientHello in any response message.  It MUST NOT include this extension in any of the four messages if it has no appropriate flag-type to indicate.  This extension MUST NOT be included empty. A server MAY indicate support for flag-type features in a flags extension of CertificateRequest (CR).  Flag-type extensions that have been indicated in CR (and only such extensions) MAY be also be present in a flags extension of the Certificate (CT) message sent by the client.  However, a client MUST NOT indicate support for any flag-type feature in a Certificate message that was not previously indicated by the server in its CertificateRequest message. A server MAY indicate support for flag-type features in a flags extension of NewSessionTicket (NST).  This message has no client-side response. In summary, unsolicited flags may appear only in ClientHello, CertificateRequest, and NewSessionTicket. </del> An implementation that receives an invalid tls_flags extension MUST terminate the TLS handshake with a fatal illegal_parameter alert.

Reviewer comments:
Does it make sense to define a "echo this back" flag? Just thinking out loud. Argument against it is that clients will just always add that flag/extension ...
An empty extension remains as a cheaper option.
I'm not sure that you want to publish a document with a reference (even if informative) to the scas draft. Other than that, this is the right way to structure this, provided a couple of issues are resolved. I've suggestions for each.I proposed some simplifications and clarifications. Along with NAME proposed changes, I think this is good to go.

Revised text:
3. <ins> Any TLS implementation that intends to propose or indicate support for a flag extension SHALL send this extension with the relevant bits set.  It MUST NOT send this extension empty -- with a length of zero. This specification does not require every flag extension to be acknowledged.  Acknowledging a flag extension is typically needed to inform the peer proposing the extension that the other side understands and supports the extension, but some extensions do not require this acknowledgement. A flag proposed by the client in ClientHello (CH) that requires acknowledgement SHOULD be acknowledged in either ServerHello (SH), in EncryptedExtensions (EE), in Certificate (CT), or in HelloRetryRequest (HRR) as the corresponding flag document specifies. Similarly, a flag proposed by the server in the CertificateRequest (CR) message that requires acknowledgement SHOULD be acknowledged in the client's Certificate (CT) message.  A flag proposed by the server in the NewSessionTicket (NST) message is never acknowledged as there is not client-side response message. Multiple flags can be proposed or acknowledged in the same extension. In all of the above cases, a flag MUST NOT be acknowledged in SH, EE, CT, or HRR without first having been proposed in CH or CR. Unsolicited flags may appear only in CH, CR, and NST.  And endpoint that receives an unsolicited flag in another message (HRR, SH, EE, or CT) MUST generate a fatal illegal_parameter alert. </ins> A client that supports this extension and at least one flag extension SHALL send this extension with the flags field having bits set only for those extensions that it intends to set.  It MUST NOT send this extension with a length of zero.  An implementation that receives an invalid tls_flags extension MUST terminate the TLS handshake with a fatal illegal_parameter alert.