Change:
This allows clients to determine whether an authorization already exists in a way most likely to be relevant to their use cases. It also allows clients which are not in a position to obtain authorizations but which may wish to issue certificates under existing ones to test for their existence without spamming the database with unused authorizations. NAME thoughts?
NAME Have you been seeing the unused auths become a recurring problem in your client? (I have in mine, and although that's still a bug in my code, I wonder if it would be helpful to know authoritatively from the ACME server that a challenge is already under way.)
I haven't. I keep track of which hostnames have successfully completed authorizations. I'd rather not have to keep track of that, though - my client operates on the principle of keeping as little state as possible. The less state kept, the less that can be messed up, the less that can be desynced.
For example if a different client on a different machine uses the same account key, there could be a usable authorization it doesn't know about. There's an authorization enumeration endpoint specified in the directory, but I think this conditional creation covers 99% of the use cases of that endpoint.
I like the general idea of making authorization reuse more straightforward, but I'm not sure this is the best approach. For instance, the field on the registration object in theory makes this possible, though it may be onerous to fetch all of the authorizations if you only care about one. If we wanted to make that easier, we could specify a way to look up existing authorizations by name and pending / valid status. Or, another alternative: Say that in response to new-authz, the server may choose at its option to reply with 302 Found to an existing valid or pending authorization (but not an expired or invalid one). In general the server would presumably choose to do so based on how much time was left until the relevant authorization expired, because it would be annoying to redirect to an authorization that was about to expire.
I considered that initially, creating or redirecting based on the expiry. The issue I think is that the client is in the best position to know how much time it needs, or maybe you want to renew the authorization for some reason. I think there are likely to be hazards to rendering it impossible to create a new authorization for a while. Moreover it's a protocol change. I think if the client opts in to it, it's okay. The only difference is you pass "existing": "accept".

Discussion:
to sign the request.  Once created, the authorization may only be updated by that account. <ins> When submitting a new authorization request, the key "existing" with a string value MAY be included in the resource object.  This object is not considered part of an authorization resource but controls request processing as described below. If the authorization request specifies "existing" with a value of "accept" or "require", before proceeding, the server SHOULD determine if there are any existing authorization resources for the account and given identifier which are presently valid.  If one or more such authorizations exists, a response SHOULD 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.  Otherwise, if the "existing" item was "require", status code 404 (Not Found) is returned; if it was "accept" or was any other value or was absent, processing continues as follows. </ins> Before processing the authorization further, the server SHOULD determine whether it is willing to issue certificates for the identifier.  For example, the server should check that the identifier