Original text:
For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see <del> identifier-authorization).  For final orders (in the "valid" or "invalid" state), the authorizations that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. </del>  A URL that a CSR must be POSTed to once all of the order's authorizations are satisfied to finalize the order.  The result of (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 <del> resource. </del>  Once the client believes it has fulfilled the server's requirements, it should send a POST request to the order resource's finalize URL.

Reviewer comments:
This PR clarifies that a client SHOULD NOT assume that the "identifiers", "authorizations" or "challenges" arrays returned in various server response objects are sorted. This PR also clarifies that while some have a 1:1 relationship between order identifiers and order authorizations this isn't a universal truth. This resolves URL
NAME Is 6 days without any feedback on-list sufficient to merge?
On the reuqest, there are two arrays returned, one for the and one for the . However, there is no order specified in ACMEv2. As two arrays are returned (and no hash), this might imply that the order of matches the order of . This is not specified right now. Having this specified would allow clients to know in advance for which identity they are requesting the authorization challenge before requesting the URL, e.g. for better error reporting. Also ok would be to just explicitly specify that the order is not guaranteed or the number of entries is not guaranteed to match in order to make it more clear to developers. cf. URL
From the outcome of the linked conversation, we should just specify that no specific order is guaranteed.
:+1: - URL I will start a mailing list thread since this is a new SHOULD NOT.
Looks good to me; let's wait a little bit for feedback on-list.

Revised text:
For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see  <ins> identifier-authorization).  The authorizations required are dictated by server policy and there may not be a 1:1 relationship between the order identifiers and the authorizations required. For final orders (in the "valid" or "invalid" state), the authorizations that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. </ins> A URL that a CSR must be POSTed to once all of the order's authorizations are satisfied to finalize the order.  The result of (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  <ins> resource.  Clients SHOULD NOT make any assumptions about the sort order of "identifiers" or "authorizations" elements in the returned order object. </ins> Once the client believes it has fulfilled the server's requirements, it should send a POST request to the order resource's finalize URL.