For minor version releases of the software we release we clone the repository as a version branch. This process is a holdover of using mercurial years back when branching wasn't a solid workflow process. On the server that hosts the repository we have push hooks to prevent pushing commits to version repos which haven't also been pushed to newer version repos (ex: cannot push a commit to version 6.1 if it's not in 6.2).
Due to this setup, when working on patch versions (6.1.x) the code will be modified and tested on the 6.1 repo, and have the Differential Revision published on that repo. However when ready to land, we `arc land --hold` on the 6.1 repo, merge the commit into 6.2 and push upstream into 6.2, followed by pushing 6.1 upstream. As a result of that push, the Differential Revision will have it's repository field updated to the 6.2 repo. The second push into 6.1 upstream does not update the Differential Revision.
In this situation it would convenient to have a way to turn off this behavior, though I'm not sure how that would work - whether it would need to be an option on the originating repo to "lock-in" the revisions, on the other repos to "not-steal" revisions, or an arc flag even. The current behavior is undesirable for our workflow as all revisions end up on the repo for the current/stable version - looking up what reviews have taken place for work developed on a released version requires looking at revisions by date-range and checking the list of commits to see if they exist in version repos - then manually switching the repository field back to the right repo.