Original text:
The status code indicates that the server understood the request but <del> refuses to authorize it.  A server that wishes to make public why the </del>  request has been forbidden can describe that reason in the response payload (if any).

Reviewer comments:
In its current wording, I interpret to allow to be used in the following two situations: The requested operation is forbidden in the current state of the resource. The requested operation is forbidden (for the user identified) by the provided authentication credentials. This ambiguity is established in the following paragraph: The ambiguity is somewhat lifted (but not entirely) by the last sentence: However, I believe the ambiguity exists and causes a lot of developers to believe that is only applicable to authorization errors. I think the wording in the previous paragraph: …the example given in : …and the wording in : …as well as existing practice establishes that is the correct status code to respond with when the requested operation is not allowed in the current state of the application (use-case 1 above), regardless of the header provided. Introducing the ambiguity of only being applicable to the provided authorization when authorization is available makes the status code harder to reason about and therefore harder to use in practice. Would it be possible to remove this ambiguity somehow? Here's some suggested wording:
ISTM that the phrase "authorize it" in the first sentence of 6.5.3 is the root of the issue. I note that 2616 used "fulfill it" instead; we should dig around and see if that was an intentional change.
I agree "authorize it" is the root issue, but think it's exacerbated by the following paragraph. It would be good to clarify the entire section to make it obvious that the presence of an header doesn't require the semantics to change.
Discussed in Montreal; ok to change.
The change from “authorize” to “fulfill” helps to resolve the ambiguity, although I would like to see a in the following paragraph: >If authentication credentials were provided in the request, the server consider them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials.
I don't think a "MAY" helps here. The current text is: That's a statement of fact. If the credentials would have been sufficient, there wouldn't be an error. (It does not necessarily imply that things would have worked with different credentials).
I think that’s exactly what the current text implies: That sufficient credentials would have lead to a successful request, regardless of the state of the resource. If we take the example from RFC 7807, there is nothing that a change of credentials can do to make the request succeed — the credit is out regardless of the authorisation.
Question: this change makes 429 a specialization of 403, right?
But that proposed "MAY" isn't permissive. This is a statement, not necessarily of fact, but of one likely possibility. Perhaps "the server considers" => "the server might consider"

Revised text:
The status code indicates that the server understood the request but  <ins> refuses to fulfill it.  A server that wishes to make public why the </ins> request has been forbidden can describe that reason in the response payload (if any).