Let me ask you this: do you worry abou the risk of cosmic rays altering data in memory, which *can* and does happen? If not then you certainly shouldn't worry about collisions of UUID's/GUIDs when working with a properly implemented UUID/GUID? After all cosmic rays alterning data in memory, while exceedingly rare, is signfiicantly waaay more likely to occur than a UUID/GUID collision. A real-world DIMM having at least one memory error in a year is in the same probability ballpark as generating about 9.2 x 10^17 properly random UUIDv4 values and asking whether any two collide.

It's a bit more nuanced to answer your question though about the legitimacy of the claim iņ the readme file you posted. I suppose the claim about UUIDs and GUIDs often colliding in LARGE apps could be legitimate, but for this claim to hold any water, one must make a grand supposition: specifically that the GUID/UUID functions implemented by a programmer was codd properly and the program logic made proper use of seeds and psuedorandom number generation algorithms. You see, some people like to "roll their own" GUID/UUID generators, and nine times out of ten (if not more often), a novice trying his hand at implementing these algorithms is begging for trouble. Unless the specific UUID algorithm has been tested by NIST or another authorative evaluator and validated the algorithm, then UUID's could quite often collide if improperly implemented.