If your tool moves comments forward to newer changesets (ideally with some sort of code ensuring it's in the right place) then that's done automatically for you.
Reviewable does this with an algorithm that ensures the code context is similar, with a visual warning if the comment might be in the wrong place. (Shameless plug!)
Usually you can quickly click through the different changesets and see all the old comments. In my experience, it maybe needs one more click to follow the reference compared to similar comments referencing the current changeset.
Github can show a list of unresolved comments, and with a single click jump to the location in the state of the specific commit the comment was written at. No need to cycle though commits / state at each commit without comments.
I see, I focused on how to deal with such a "see previous changeset" comment, when the question was really about whether there is a need to make such comments.
Answer, just like with the non-changeset oriented workflow, it depends. If the new PR update deletes the associated lines of code, there is arguably a need for those types of comments to be manually added with the current interface, but not so with a changeset oriented interface.
I like the append only nature of a changeset oriented interface.
But I find this type of conversation quite fiddly to do in pure text without reference to examples and the actual use of both styles, so forgive me if this is still unclear.
"This changeset still has the problem I drew attention to in my review of the previous changeset. Please see the comment there."
? I'm just curious how that works; I haven't used changesets much but it seems like this would be one inconvenient aspect.