The RFC defining them says they're the same and has since the earliest draft I can find, also from 2002. You should offer more explanation when you take a stance contrary to what is well documented.
Check my other comment as to how GUIDs are created in many ioquake3 forks. They MD5 hashed a randomly generated file.
Theoretically speaking, UUIDs have a semantic guarantee that each generated identifier is unique across all systems, times, and contexts, whereas cryptographic hashes are deterministic functions (i.e. they produce the same output for the same input), there is no inherent randomness or timestamping, unless you deliberately inject it such as the way ioquake3 forks did with GUID.
UUIDv4's output size is 122 bits usable, so 1 in 2^122 chance of collision, whereas SHA-512 and BLAKE2b has 512 bits, which has a 2^256 collision resistance, bound by the birthday problem.
In any case, SHA-256, SHA-512, BLAKE2b (cryptographic hashes) are unique in practice, meaning they are extremely unlikely to collide, more so than UUIDv4, despite UUIDv4 being non-deterministic, while cryptographic hashes are deterministic.
Of course, you should still know when to use cryptographic hashes vs. UUIDs. UUIDs are good for database primary keys, identifying users globally, tracking events, and the rest, such as verifying file content, deduplicating data by content, and tamper detection is the job of a cryptographic hash.
But to get to the chase: GUIDs (Globally Unique Identifiers) are also known as UUIDs (Universally Unique Identifiers), so they are the same!
I hope this answers OP's (kbolino) question. He was right, GUIDs are the same as UUIDs. Parent confused GUIDs with cryptographic hashes, most likely.
---
FWIW, collision resistance (i.e. birthday bound) is not improved by post-quantum algorithms. It remains inherently limited by 2^{n/2}, no matter what, as long as they use hashing.
---
TL;DR: GUIDs (Globally Unique Identifiers) are also known as UUIDs (Universally Unique Identifiers), so they are the same, i.e. GUIDs and UUIDs are NOT different!
So, in this case, GUID is the MD5 hash of the generated qkey file. See "CL_GenerateQKey" for details.
> On startup, the client engine looks for a file called qkey. If it does not exist, 2KiB worth of random binary data is inserted into the qkey file. A MD5 digest is then made of the qkey file and it is inserted into the cl_guid cvar.
UUIDs have RFCs, GUIDs apparently do not, but AFAIK UUIDs are also named GUIDs, so...
The GUID can certainly be a hash.