Original text:
can be accessed in the "terms-of-service" subfield of the "meta" field in the directory object, and the server MUST reject new-account requests that do not have the "terms-of-service-agreed" set to <del> "true". </del>  If the client wishes to update this information in the future, it sends a POST request with updated information to the account URI. CAs that use ACME to automate issuance will need to ensure that their servers perform all necessary checks before issuing.  10. There are certain factors that arise in operational reality that

Reviewer comments:
It would be nice if it could be clarified whether "--agree-tos"-like switches that don't require the user to whitelist specific TOS versions are acceptable in ACME clients. certbot has one. On the other hand, the author of acmetool refuses to implement "--agree-tos"-like functionality without clarification in the spec, making it impossible to completely automate renewal with certbot. (hlandau/acme). If it isn't acceptable then we have the absurd situation of the de-facto official client being out of spec. (Note: I accidentally opened the issue against the wrong repo first (URL).)
There's a limit to what we can do here, because switches like this are not part of the protocol. We can say, however, that clients SHOULD NOT auto-agree by default (so that there's some user interaction at some point, even just at config time), and that CAs need to keep in mind that clients can automate. I'll post a PR shortly.
Thanks for the quick reply, but pr doesn't really answer the question. The question wasn't about the default case (ie, it's not about doing away with --agree-tos entirely), but about giving users the choice to blanket accept future versions of TOS by continued usage, after the initial configuration / initial acceptance of TOS, instead of having to change a config file everytime a new TOS is rolled out. From your answer and PR, I'm still not sure what your opinion on that question is.
Note that the protocol specifically handles only initial acceptance. If the CA wants a user to explicitly agree to a new ToS (this is exceptionally rare - most ToS have auto-update language), it does so by sending an error message with a link to a webpage with instructions for agreeing anew. So the only question that needs to be answered is whether a user can specify agreement to the current terms on initially running the client.
LE does it, breaking users renewals (for acmetool users). I'm concerned with automating renewals (and also automated from-scratch deployments), and this issue is specifically about keeping setups working without manual intervention. This is currently possible with certbot and not possible with acmetool, because the author is unsure if the spec allows what certbot already implements. "An error message with a link to a webpage" means broken automation (for acmetool, currently).
This is only an issue with the older revision, which is what Let's Encrypt currently implements. The current revision of the specification has clarified matters in this regard and it is unlikely, at least for Let's Encrypt, that the need for manual re-assent with regard to acmetool will occur again, especially after Let's Encrypt starts supporting . So this issue has already been rectified in the specification.
NAME LE does not require explicit agreement to new ToS. See the Subscriber Agreement at URL

Revised text:
can be accessed in the "terms-of-service" subfield of the "meta" field in the directory object, and the server MUST reject new-account requests that do not have the "terms-of-service-agreed" set to  <ins> "true".  Clients SHOULD NOT automatically agree to terms by default. Rather, they SHOULD require some user interaction for agreement to terms. </ins> If the client wishes to update this information in the future, it sends a POST request with updated information to the account URI. CAs that use ACME to automate issuance will need to ensure that their servers perform all necessary checks before issuing. <ins> CAs using ACME to allow clients to agree to terms of service should keep in mind that ACME clients can automate this agreement, possibly not involving a human user.  If a CA wishes to have stronger evidence of user consent, it may present an out-of-band requirement or challenge to require human involvement. </ins> 10. There are certain factors that arise in operational reality that