The reasons for this is a bit technical, but here goes.
WordPress.org provides an SVN repository for each plugin on their system.
SVN is a "version control" system used by developers to manage their source code and publish releases. When a developer is ready to release, the procedure is something like this:
- "Commit" all your source code to your SVN repository.
- Update your "readme.txt" to indicate your "stable" version
- Create an "SVN Tag" for that release.
If your new stable version is "1.2.3", then your SVN tag is also "1.2.3".
This SVN tag is a bit like a "copy" of your source code at a specific point in time.
Shield uses these SVN Tags to demarcate what files should and should not be present in a release. If we go to the SVN tag "1.2.3", we'll be able to see all the files for the plugin at that version.
But let's say the developer discovers a "small" bug - one that wouldn't affect anyone seriously, but might want to fix it for anyone else but not go through the "major hassle" (note: it's not a major hassle) of releasing a new version.
The correct procedure is to release version "1.2.4". It's different after all.
Unfortunately, developers can take shortcuts and instead of releasing a new Tag 1.2.4, they jump into the code for the old tag, and update their files.
What does this mean?
This means that there are now 2 different "editions" of the same version for "1.2.3". If you're running the older edition and Shield scans your site, then it's going to detect differences.
It'll alert you and it'll even repair the file. But repairing the file wont help... it'll keep finding the different files.
This will keep happening until you upgrade your plugin to the next version if and when it's released.
There is no way to automatically detect plugins that do this.