Yes you're correct. In practice we've seen many codebases that generate UUIDv4 by a poor PRNG or a codebase-seeded PRNG. For example we've seen bash `$RANDOM %

Yes you're correct. In practice we've seen many codebases that generate UUIDv4 by a poor PRNG or a codebase-seeded PRNG. For example we've seen bash `$RANDOM % 10` instead of /dev/urandom, Java Random instead of SecureRandom, or misinformed home-grown hashing attempts as described in the article, or a constant seed at the top of the code. The UUID spec allows these; the XID spec prohibits these. You asked: what would prevent you from doing a broken implementation of an XID? In a case such as that, an advantage of an XID is a correct implementation is easier to see during code review, easier to verify during continuous integration, and easier to discuss with teams that aren't as familiar with PRNGs, seeds, crypto, and UUID v1-v5. These are people-pragmatic benefits not information-theoretic benefits.