Change:
I believe they are unnecessary. The server can set its own policy on whether to give back an existing or a new authz, and the client can choose to accept or reject that. Hugo also pointed out on-list that the status codes for these are inconsistent with the status codes for new-account. If we keep these, we'd want to fix that. But simpler to delete, I think.
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

Discussion:
The identifier itself. <del> How an existing authorization should be handled.  Possible values are "accept" and "require". </del> Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the identifier.  For example, the server should check that the identifier

(Forbidden) error, with a problem document describing the reason for the rejection. <del> If the authorization request specifies "existing" with a value of "accept" or "require", before proceeding, the server SHOULD determine whether there are any existing, valid authorization resources for the account and given identifier.  If one or more such authorizations exists, a response SHOULD be returned with status code 303 (See Other) and a Location header pointing to the existing resource URL; processing of the request then stops.  If there are multiple such authorizations, the authorization with the latest expiry date SHOULD be returned.  If no existing authorizations were found and the value for "existing" was "require", then the server MUST return status code 404 (Not Found); if it was "accept" or was any other value or was absent, processing continues as follows. </del> If the server is willing to proceed, it builds a pending authorization object from the inputs submitted by the client.