It appears you are asking essentially about what Subversion developers would refer to as "forward history searching": given a particular path and revision, locate copies made of that path in younger revisions. One practical use of this functionality is, "Hey, I know that version 1412 of ^/trunk/lib/foo.c had a major bug in it -- which of our software's various release branches and tags need to receive a fix for that bug?"
From a core technology perspective, this is challenging because Subversion only internally tracks history in the reverse direction -- for each "node", it knows its ancestors. But successors aren't tracked.
Your reference to "unticking" the "Stop on copy/rename" option leads me to believe that you're using a graphical Subversion UI such as TortoiseSVN. I'm not deeply familiar with that UI, but I have this (ancient) memory that it maintains a local cache of repository history. It's feasible that such a cache could better answer questions of "forward history searching" than Subversion's core APIs and command-line client could, but of course, the TortoiseSVN developers would have to make a conscious decision to expose that functionality.
Short of such a thing, you'd need to find or build tooling that takes, say, the output of svn log -vq
on the root of the repository, tracks all copies back through time—building a sort of historical tree for each path—and then allows you to locate a given point on the tree and walk forward in revision time through its various forks and dead-ends while reporting what it finds.
Unfortunately, I know of no such tooling.