Change:
willing to receive such frames on this connection. An endpoint MUST NOT send DATAGRAM frames until it has received the <del> max_datagram_frame_size transport parameter with a non-zero value. An endpoint MUST NOT send DATAGRAM frames that are larger than the max_datagram_frame_size value it has received from its peer.  An endpoint that receives a DATAGRAM frame when it has not indicated </del> <ins> max_datagram_frame_size transport parameter with a non-zero value during the handshake (or during a previous handshake if 0-RTT is used).  An endpoint MUST NOT send DATAGRAM frames that are larger than the max_datagram_frame_size value it has received from its peer. An endpoint that receives a DATAGRAM frame when it has not indicated </ins> support via the transport parameter MUST terminate the connection with an error of type PROTOCOL_VIOLATION.  Similarly, an endpoint that receives a DATAGRAM frame that is larger than the value it sent

Discussion:
Section 3 says: “An endpoint MUST NOT send DATAGRAM frames until it has received the maxdatagramframesize transport parameter with a non-zero value.” I guess you assume that having received maxdatagramframesize in a previous connection, when 0-RTT is used, counts but interpreting this MUST strictly, you cannot send datagrams in 0-RTT. Maybe that can be clarified. Also if datagrams are used with 0-RTT but for some reason are not supported by the server anymore, it would actually be useful to have a more specific error message if the connection is closed by the server.
This is already discussed in Section 3: That's not how 0-RTT works in QUIC. If the server wishes to no longer support datagrams, it MUST reject 0-RTT data and therefore it won't see those DATAGRAM frames.
NAME given David's explanation, are we OK to close this one?
I know that this is explained in section 3, but what I'm saying is that the MUST NOT in the text I cited contradicts this text (if you interpret the MUST NOT strictly but maybe I'm to strict here). So to be more clear one could say: "... MUST NOT send DATAGRAM frames until it has received the maxdatagramframesize transport parameter with a non-zero value in the handshake, or a previous handshake if 0-RTT is used." Regarding the server not supporting datagram in 0-RTT anymore, my assumption was that if the server does not have any state if datagram was used but does not support datagram anymore for some reason, it would receive a 0-RTT with a datagram and probably close the connection based on this text: "An endpoint that receives a DATAGRAM frame when it has not indicated support via the transport parameter MUST terminate the connection with an error of type PROTOCOLVIOLATION." I guess you are saying if 0-RTT and datagram is used the server MUST remember that datagram was negotiated?

However, there is also this text: "If a client stores the value of the maxdatagramframesize transport parameter with their 0-RTT state, they MUST validate that the new value of the maxdatagramframesize transport parameter sent by the server in the handshake is greater or equal to the stored value; if not, the client MUST terminate the connection with error PROTOCOL_VIOLATION." So this would mean larger datagram are accepted in 0-RTT but then if the server indicates a smaller value for 1-RTT, the connection needs to be terminated? Why? Also if datagram was used in the previous connection, then 0-RTT is used without datagrams, the server can still not indicate in the handshake that is not supporting datagram anymore? All I'm saying is that these things could be further clarified to avoid any doubt.
Adding "or a previous handshake if 0-RTT is used" is fine by me. Your assumption is incorrect. If servers used to support datagram and they accept 0-RTT, they must also support datagram in the new connection. That's spelled out here: Clarifications are always good. Can you send a PR?