Original text:
the date format defined in For pending orders, the authorizations that the client needs to <del> complete before the requested certificate can be granted (see </del>  identifier-authorization).  For final orders, the authorizations <del> that were completed.  Each entry is a dictionary with parameters describing the authorization: </del>  The status of the authorization.  This field MUST have the same value as it does in the underlying authorization object. A URL for the certificate that has been issued in response to this order. <del> The elements of the "authorizations" array are immutable once set, except for their "status" fields.  If any other part of the object changes after the object is created, the client MUST consider the order invalid. </del>  The "authorizations" array in the challenge SHOULD reflect all authorizations that the CA takes into account in deciding to issue, The order object returned by the server represents a promise that if the client fulfills the server's requirements before the "expires" time, then the server will issue the requested certificate.  In the <del> order object, any object in the "authorizations" array whose status is "pending" represents an authorization transaction that the client must complete before the server will issue the certificate (see identifier-authorization).  If the client fails to complete the required actions before the "expires" time, then the server SHOULD change the status of the order to "invalid" and MAY delete the order resource. </del>  The server MUST issue the requested certificate and update the order resource with a URL for the certificate as soon as the client has proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations" <del> array, with the state "valid". </del>  Once the client believes it has fulfilled the server's requirements, it should send a GET request to the order resource to obtain its these requests.  The authorization object is implicitly tied to the account key used to sign the request. <del> When a client receives an order from the server with "pending" entry in the authorizations array, it downloads the authorization resource by sending a GET request to the indicated URL.  If the client initiates authorization using a request to the new authorization resource, it will have already recevied the pending authorization object in the response to that request. </del>  6.5.1.

Reviewer comments:
As discussed at IETF 97, this PR removes the "requirements" abstraction, and changes the "requirements" field in an application/order object to be an "authorizations" field. This is a replacement for .
Let's Encrypt tell me that they have had a few reports of buggy clients creating enough pending authorizations to saturate their rate limits, so they need a way for clients to clear these out. These clients are also not keeping around authorization URLs, so they can't just go them. My proposed solution would be to re-add the "authorizations" field to the account object, which got lost in the refactor in or so. Together with deactivation, enabling clients to enumerate authorization URLs would solve this problem. You could also envision a more direct solution, offering an endpoint that just deletes all pending authorizations for a client or client+identifier.
This is definitely too specific to these buggy clients. For the flow, the list of orders is sufficient. It's true that technically you can create authorizations through a separate, optional, flow. But Let's Encrypt has no plans to implement that flow, because other CAs have said they cannot / would not implement it, so Let's Encrypt implementing it would split the market. I'm inclined to say let's not complicate the protocol, and hypothetical clients that want to do the flow with some hypothetical server need to keep proper track of their authzs. Also, I think the particular issue with hitting limits for pending authzs can be solved in several ways without modifying the protocol.
If is merged, I would expect that a reasonable ACME server supporting new-authz would return an exiting authz, instead of giving a rate limit error. Or return existing authz from the beginning.
Closing as a result of WG decision at IETF 98

Revised text:
the date format defined in For pending orders, the authorizations that the client needs to  <ins> complete before the requested certificate can be issued (see </ins> identifier-authorization).  For final orders, the authorizations  <ins> that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. </ins> The status of the authorization.  This field MUST have the same value as it does in the underlying authorization object. A URL for the certificate that has been issued in response to this order.  <ins> The elements of the "authorizations" array are immutable once set. If any change is made to the array after the object is created, the client MUST consider the order invalid. </ins> The "authorizations" array in the challenge SHOULD reflect all authorizations that the CA takes into account in deciding to issue, The order object returned by the server represents a promise that if the client fulfills the server's requirements before the "expires" time, then the server will issue the requested certificate.  In the  <ins> order object, any authorization referenced in the "authorizations" array whose status is "pending" represents an authorization transaction that the client must complete before the server will issue the certificate (see identifier-authorization).  If the client fails to complete the required actions before the "expires" time, then the server SHOULD change the status of the order to "invalid" and MAY delete the application resource. </ins> The server MUST issue the requested certificate and update the order resource with a URL for the certificate as soon as the client has proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations"  <ins> array. </ins> Once the client believes it has fulfilled the server's requirements, it should send a GET request to the order resource to obtain its these requests.  The authorization object is implicitly tied to the account key used to sign the request.  <ins> When a client receives an order from the server it downloads the authorization resource by sending a GET request to the indicated URL. If the client initiates authorization using a request to the new authorization resource, it will have already recevied the pending authorization object in the response to that request. </ins> 6.5.1.