Put it into a comment or into one of todo.txt, features.txt, ideas.txt, under docs/ or in README?

Yep, or make a ticket in whatever issue/ticket/work management system you use. Everywhere I’ve worked has always had some kind of “future stuff we’d like to do” project.

But then rather than leaving a non-blocking review, why not leave a blocking review and approve it as soon as the author responds with a link to the ticket or adds it to TODO.md?

If it's important enough to be tracked then I'd want to make sure that it's been filed properly. It's too easy to forget about such a trivial task, especially in a time crunch.

Because we’re pragmatic, and I trust my teammates to handle things like that without the need to babysit them or block them over trivial tasks?

I trust that it will get done. It is not important to me, whether it happens before the PR goes in or afterwards.

What's the point of leaving a review comment then?

Because it belongs in to the PR and only the Author knows the answer: his thoughts and rationale for the change and behaviour. Sure I could just guess, but then it's essentially poking in legacy code. The point of it being not legacy code is, that the person is still around, so he should write down his reasons, so that they are documented.

Sure, what I'm trying to say is that you need to design a process which ensures that these non-blocking review comments get organized properly, and enforce it. If you need the author to add your comments to TODO.md then that should once again become a blocking review.

I do not want to prescribe the author what he needs to do. I only want to make sure that it was an intentional choice to not do that.