> most of the time, the review occurs when work seemed good enough for the requirements

Most of the time, a blocking review should contain information that the coder didn’t have, which changes their own perception about the readiness of the code: a bug they didn’t notice, a pattern in the codebase they didn’t know about, etc.

If there is any debate about whether a change is necessary it should probably be a “nit” with an approving review.

The point of “request changes” is to flag branches that everyone can agree need changes.