Change:
I found an interesting regression when implementing the delayed ack extension. The extension allows the sender of the data to control the max ack delay and the ack gap. In general that's a good idea, but not for the 2 RTT of the connection. Once the client obtains the 1RTT key, it will start receiving data sent by the server in "false start". At that point the client has assessed the RTT of the connection, but the server has not. The "max ack delay" sent by the server is a guess based on statistics. It will typically be longer than recommended values like RTT/4. The effect is that the first ACKs are sent too late, which has a cascading effect with some congestion control algorithms. My fix was to use the values locally computed by the client until the session is confirmed and the server can send accurate "ack frequency" frames. Not sure whether we should have text about that in the draft.
I'm not completely clear on the details here, so hopefully you can clarify. Is the server sending an ACK_FREQUENCY frame in 0.5RTT before it has any RTT samples? If so, yes I would say that's a bad idea and we should add a SHOULD NOT to advise against that. And the regression is that slow start is slowed down substantially vs the default behavior of sending an ACK every 2 packets? Or is there another regression? Possibly this issue is a variation on about recommendations and potential pitfalls of this extension frame?
At 0.5 RTT, the server will start sending data frames: HTTP settings for example, or maybe responses to client requests in 0-RTT packets. As you say, the server should not send an ACK FREQUENCY frame in 0.5RTT before it has any RTT samples. Let's assume it doesn't. The client knows that Min Ack Delay has been negotiated. In that case, my first implementation of the extension was completely deferring to the server, and just setting Ack Delay Max to the parameter advertised by the server. After all, the draft does says that the ACK FREQUENCY frame carries an update to the peer's "maxackdelay" transport parameter. That was be by the book. But it was also causing regressions in a number of performance tests, because the value in the TP is typically an upper bound. The acks were sent too late, the connection was ramping up too slowly.
Thanks, presumably the client is setting "Packet Tolerance" to a value larger than 2 in its ACK_FREQUENCY frame? If so, that makes sense. In the "Motivations" section, the existing draft says: "Starting a connection up quickly without inducing excess queue is important for latency reduction, for both short and long flows. The sender often needs more frequent acknowledgments during this phase." But maybe there needs to be more cautionary text later in the draft, and less text in "Motivations"?
Summarizing editors' discussion: the issue here seems to be that in an interpretation of the mechanism, the client could change its behavior after receiving but before receiving an ACK-FREQUENCY frame. This should not happen... the goal of is to negotiate future use of ACK-FREQUENCY frames. Until an ACK-FREQUENCY frame is received, an endpoint continues with RFC 9000 behavior. We will add text to this effect. NAME does this work for you?
NAME yes, that makes sense. I will check that the picoquic code does that.
Works for me.

Discussion:
independent of whether it also sends the min_ack_delay transport parameter or not. <ins> Receiving a min_ack_delay transport parameter indicates that the peer might send ACK_FREQUENCY frames in the future.  Until an ACK_FREQUENCY frame is received, receiving this transport parameter does not cause the endpoint to change its acknowledgement behavior. </ins> Endpoints MUST NOT remember the value of the min_ack_delay transport parameter they received.  Consequently, ACK_FREQUENCY frames cannot be sent in 0-RTT packets, as per Section 7.4.1 of QUIC-TRANSPORT.