> However usually code is easy to change, so defaulting to "just merge it" and creating followup tasks is often the cheaper approach than infinite review cycles.

I wish this was the "default" mindset everywhere, especially in those cases where you have that one colleague that loves to nitpick everything and doesn't see an issue with holding up both releases and wasting your time over menial pedantic stuff. It would be so much easier to merge working code and let it work, and keep those TODOs in the backlog (e.g. trash).

In a sane world, code review would be like:

  1. Will this work and not break anything? We checked it, it's okay. There are no apparent critical or serious issues here.
  2. Here's a list of stuff that you can change if you wish, here's why it might be an improvement.
  3. Okay, we have some left-over nice to haves, let's keep track of those for later (or not) and merge.

It gets infinitely worse if you're working on 3 projects in parallel and the person wants long winded calls or starts nitpicking about naming, or wants things done exactly their way as if it's the only way (doubly worse if their way is actually worse by most metrics and tastes).