Hi @mje,
Gotcha - I believe my answer holds. It shouldn't be a problem.
You mean the portion of the challenge that you need to provision the TXT record? The spec calls that just a "token" (which is separate from the replay nonce that I mentioned "aging out" in my response).
Unfortunately for this kind of documentation I think the draft RFC is the only thing going right now. I agree that a nicer "flow" overview would be great to have.
Nonce means (more or less) "number used only once" and in the case of ACME it's there on every request to prevent a MITM (say, like our CDN) from replaying requests. You can read more about it in Section 6.4 of the ACME draft.
For Let's Encrypt's particular implementation of ACME nonce's there is a fixed sized bucket of "active" nonces and so if you get one now in a few hours time we might have given out enough other nonces that yours is kicked out of the active set (roughly speaking) and will result in a nonce error that requires retrying with a fresh nonce.
Both pending and valid authorizations have an explicit lifetime (the "Expires" field), totally separate from the nonce validity. At present pending authorizations expire 7 days after creation, valid authorizations expire 60 days after the point of validation but that will soon be changing to 30 days.
Hope that helps clear things up!