Change:
makes an HTTP DELETE request to the continuation URI. If the request is successfully cancelled, the AS responds with an <del> HTTP 202.  The AS MUST revoke all associated access tokens, if possible. </del> <ins> HTTP 202.  The AS SHOULD revoke all associated access tokens. </ins> 6.

Discussion:
I don't know much about the GNAP revocation plan, but it seems like having text specifying 'MUST if possible' is the same as SHOULD, per RFC 2119. Maybe I'm missing something :) I read the contributing doc, but if PRs as contributions aren't acceptable, please let me know.
PR text contributions are just fine, they fall under the IETF contribution guidelines. Thank you! See and for discussion on token revocation.
Thanks, those both deal with token rotation; not sure if that is different than token revocation/cancelling. It seems like the "MUST invalidate the current access token ... if possible" is used in a few different places. I see it in 5.5, 6.1, 6.2. I guess I don't understand what "MUST ... if possible" means from an implementation standpoint, other than "SHOULD". (If this has been discussed on the mailing list--a quick search there didn't turn anything up.
The issues in question are specifically about what to do with old tokens under rotation circumstances, which falls under the same conversation as what to do with explicitly revoked tokens that's addressed here. I linked those issues because the same discussion of "if possible" has been brought up in those places as well (as you point out here). Before a PR like this is accepted with a normative change, we need to bring the proposal to the working group for consensus building. If you want to kick off the conversation on the list more quickly, please feel free to start a thread and link to this PR! Why the "MUST if possible" phrasing? Mostly because sometimes it's impossible to revoke a token once it's in flight. Some OAuth 2 systems today use self-contained access tokens, which by nature can't be revoked in any meaningful way. However, the requirement is that if the AS is able to revoke the tokens, then it doesn't have a choice in doing so. If it's impossible for the AS to fulfill the requirement, that's ok, but the AS doesn't get to just choose to not revoke the tokens, it just can't. To me this seems more than a SHOULD, but I could be wrong.
As currently written, this does read like a SHOULD.

If we care a lot about token revocation, we can make it a MUST and totally disallow self-contained tokens. If we don't, we need to clarify the situation, maybe by defining revocable vs. non-revocable tokens. And then say that in this instance, if the tokens are revocable, they MUST be revoked.
That was the intent of the text as it is right now. I kinda like the idea of "revocability" being a variable attribute on access tokens, as it allows us to talk about them in different ways. There's currently a stub section in the document (appendix B) for talking about the data models, and this would be part of that discussion.
The idea of specifying whether tokens are revocable or not might be useful. We might want to illustrate when we'd use one vs the other. One could imagine using non revocable tokens when the information is not critical, short lived and when maintaining state is not worth the trouble. Note that there's the potential issue of allowing rotating these tokens, while not revoking them, hereby creating new tokens without falling into the classic flow. So probably we should limit that behavior. Revocable tokens would require that current tokens be revoked (MUST) when they're rotated.
Rotating the Access Token: Editor's note: We could also use different verbs to signal whether or not the old token should be kept around or not, instead of using a token flag to do this.
Keep "MUST if possible" here. If you want two access tokens, use the grant API not the token rotation API. The rotation mechanism should be for getting a new value for an existing token and replacing it, not for minting entirely new separate tokens (which is what the grant continuation/update API is for). We need to keep "if possible" for the case of using stateless tokens (fully self-contained JWTs), and add a discussion on when it might not be possible.
Modifying an Existing Request: Editor's note: This might be subject to the "multi_token" flag, but since we're creating a NEW access token and not rotating an existing one, this seems to be a different use case. There is a solid argument to be made for always revoking old access tokens here, but we need more discussion on the boundaries for such a requirement.

If they stick around, it does make a "read" request weird because now we've got multiple access tokens sticking around associated with a grant request and no good place to put them.
I don't think we should put a strict requirement on revoking old access tokens, since it may be difficult or impossible in some implementations. At most this could be a "SHOULD" or "RECOMMENDED".