Seeing 4 previously "outstanding" warnings being flagged as "new", after a change.  The sequence of events leading to this are as follows:

1. A single line of code was modified
2. This caused a "new" warning to (correctly) be flagged
3. The same line was modified again to fix the "new" one
4. Four "outstanding" warnings, immediately above and below the changed line, were then flagged as "new"

Since this happened on a forked repo in GitHub (and was the first change since the fork), I tried to recreate the issue by forking it to another organization and running through the exact same sequence of commits that caused the issue before.  Unexpectedly, everything worked as it should have, and did not flag those issues as new for me. 

The only difference that I found was the first (and only) build of the "problem" forked repo's reference branch (`master`) was marked as `UNSTABLE` in Jenkins because it wasn't able to get some Git meta data at the time, whereas mine was successful.  I verified that the proper reference branch (`master`) was being used in both cases, although I am explicitly setting that in my pipeline code using `discoverGitReferenceBuild defaultBranch: master`.

I'm wondering if the unstable status confused the matching algorithm somehow, because it flagged issues immediately above and below the change (not sure why it didn't do that the first time the line was modified, though).  In the attached image, you'll see that line 513 was changed, and the existing issues Warnings flagged as new were on lines 510, 511, 514, and 515.  I've heard something before about the matching algorithm looking 3 lines above and below, to guard against line number changes - could this be a glitch in that logic?