A bit of interesting (I hope) information:
When manually comparing compiler-1-warnings.xml files from two consecutive builds, I can see that some entries therein differ only on their <contextHashCode> elements (and <key>, but that seems rather universal). The number of contextHashCode differences matches the reported number of fixed/new warnings.
It would seem that the calculation of contextHashCode is not entirely consistent?

The contextHashCode is used to determine whether a warning is new. It is computed from the content of the file (+- 5 lines around the warning). So if all your warnings are at line 0 then the first lines should be read. Did the content of these lines change in that build?

Maybe the contextHashCode is not built at all: is the value of contextHashCode a numbered sequence of integers in one of your warning.xml files?

.

No, the contextHashCodes look random enough. One problem, though, is that for the dynamic parser where the line number is reported as 0, the filenames are equally invalid, i.e. there is actually no file by that name.
The (proprietary, home-grown) tool that outputs these warnings does not output file names, but class names, and there's no simple relationship from one to the other.
So with no file to read I could suspect that the hash code starts off uninitialised and never gets a proper value, perhaps? Maybe seeding it with hash(filename) might be an idea that would ensure some sort of difference between files, yet not depend on line number?

However, this doesn't really explain it for the MSBuild parser. I'll have to check the relevant source code (and I will).
It also does not explain why the lists of new/fixed warnings are actually empty even if there's supposed to be e.g. 10 of each (as reported by MSBuild parser).

By the way, I respect that you don't find this a major problem, but please keep in mind that my users actually do find it bordering on Blocker. I was forced to downgrade the plugin to keep them (partly) happy...

Oh, it turns out that you're right about the sequential integers.
For those (or: the number of) warnings where the plugin reports new+fixed, the contextHashCode is indeed just an integer, apparently from the same "number space" as the value of <key>.
For the unchanged warnings, the contextHashCode does look more random (much larger numbers, even negative).

The MSBuild parser warnings in question are reported for filenames (seen in <path> element) such as "" or "C:/Windows/Microsoft.NET/Framework/v4.0.30319". The latter file is not present on the machine that parses the warnings.

Perhaps warnings in inaccessible files (i.e. without a proper context) could be excluded from the new/fixed comparison?

Hmm, I still can't reproduce the problem. The new warnings are computed using the difference of 'current' - 'reference' using the equals method. I.e. if all properties are the same then the difference should return an empty set.

What did you set in option 'Use delta for new warnings' in the configuration of the plug-in?

Code changed in jenkins
User: Ulli Hafner
Path:
pom.xml
src/test/java/hudson/plugins/warnings/parser/WarningTest.java
http://jenkins-ci.org/commit/warnings-plugin/6c04d695e3d27a06f52955a64f62bbc621066aed
Log:
JENKINS-14821 Added equals test.

'Use delta for new warnings' is unset.

The properties most likely are not the same - the contextHashCode has changed.

But even when the plugin reports e.g. "10 new" and "10 fixed", the lists of those new/fixed warnings are empty.

I'll see if I can make an easy-to-reproduce example for you