Change:
6.3.2. <del> Once a client has created an account with an ACME server, it is possible that the private key for the account will be lost.  The recovery contacts included in the registration allows the client to recover from this situation, as long as it still has access to these contacts. By "recovery", we mean that the information associated with an old account key is bound to a new account key.  When a recovery process succeeds, the server provides the client with a new registration whose contents are the same as base registration object - except for the "key" field, which is set to the new account key.  The server reassigns resources associated with the base registration to the new registration (e.g., authorizations and certificates).  The server SHOULD delete the old registration resource after it has been used as a base for recovery. In addition to the recovery mechanisms defined by ACME, individual client implementations may also offer implementation-specific recovery mechanisms.  For example, if a client creates account keys deterministically from a seed value, then this seed could be used to recover the account key by re-generating it.  Or an implementation could escrow an encrypted copy of the account key with a cloud storage provider, and give the encryption key to the user as a recovery value. The client requests recovery by asking that the server send a message to one of the contact URIs registered for the account.  That message indicates some action that the server requires the client's user to perform, e.g., clicking a link in an email.  If the user successfully completes the server's required actions, then the server will bind the account to the new account key. (Note that this process is almost entirely out of band with respect to ACME.  ACME only allows the client to initiate the process, and the server to indicate the result.) To initiate recovery, the client sends a POST request to the server's recover-registration URI, with a body specifying which registration is to be recovered.  The body of the request MUST be signed by the client's new account key pair. The string "contact" The URI for the registration to be recovered. If the server agrees to attempt recovery, then it creates a new registration resource containing a stub registration object.  The stub registration has the client's new account key and contacts, but no authorizations or certificates associated.  The server returns the stub contact in a 201 (Created) response, along with a Location header field indicating the URI for the new registration resource (which will be the registration URI if the recovery succeeds). After recovery has been initiated, the server follows its chosen recovery process, out-of-band to ACME.  While the recovery process is ongoing, the client may poll the registration resource's URI for status, by sending a POST request with a trivial body ({"resource":"reg"}).  If the recovery process is still pending, the server sends a 202 (Accepted) status code, and a Retry-After header field.  If the recovery process has failed, the server sends an error code (e.g., 404), and SHOULD delete the stub registration resource. If the recovery process has succeeded, then the server will send a 200 (OK) response, containing the full registration object, with any necessary information copied from the old registration).  The client may now use this in the same way as if he had gotten it from a new- registration transaction. 6.3.3. </del> If a client no longer wishes to have an account key registered with the server, it may request that the server delete its account by sending a POST request to the account URI containing the "delete"

Discussion:
We already removed token-based account recovery; this PR removes contact-based recovery. It was already almost entirely unspecified, due to it being a process that primarily takes place outside of ACME. Removing account recovery from ACME simplifies both the protocol and the security considerations. As an alternative, this PR adds an field to the dictionary in the directory, which the CA can use to expose account management functions such as recovery. But you can also imagine using this for more sophisticated account management functions, like associating an ACME account with some other account in a different system.
(Also threw in some editorial corrections, sorry)
The editorial corrections are good and IMO should be taken in any circumstances. I agree this change does what it says it does, so r+. One concern, which I will cross-post to the list, is that the placement of this URL in the directory means that it is not customizable; It could be a useful thing to, after a signed request, give back a URI that contains a one-time value that would help tie a browser session to a given account key. I don't see a good endpoint for such a thing at present, so the hour is probably too late for such a change.
NAME I agree that could be useful, but I can think of other, simpler ways to provide it (e.g., a link relation from a registration URI). If you think it's important, please file a follow-on issue.
NAME See my feedback on the ACME list. I disagree that this should be merged now. Could you please submit a revert and seek further discussion?
Sorry, I misunderstood. Will revert.