Multiple tracks match for a single persistent ID because of the way AppleScript handles double integers. Just like Sei said above, it has to do with AppleScripts conversion process. However, I don't know why you got the results you did with the OSX Calculator, Sei: I used that process and found the XML hex values and the returned AppleScript values to be equivalent (though with different levels of precision).
Basically what's happening is that the 'double integer' value that iTunes returns through an Apple Event is 64-bits in size. The only data type that AppleScript has with that capacity is 'Real,' so it converts the persistent ID to a real number. However, it doesn't really have the full 64 bits to use because of the way floating point numbers are stored, so it loses precision. When you convert from AppleScript's 'Real' typed value back into a 'double integer' value used by iTunes, it fills in the truncated digit(s) with zero(es) and you end up getting multiple hits for the same persistent ID. Here's a relevant post on the AppleScript mailing list about this:
http://lists.apple.com/archives/Appl.../msg00311.html
In the project I'm working on for which this has become a problem, I'm looking into the possibility of filtering by file size and date added (which is precise to the second) as a replacement for persistent ID; I figure the chance of two tracks of exactly the same number of bytes being added within one second of each other is something I can live with. It might be significantly slower to search by two criteria, though.
The other possibility is that I learn Obj-C and the Apple Events API and bypass AppleScript entirely...maybe someday, but not right now thanks!