1. ZID specifies secure random number generation. UUIDv4 does not. Thus ZID is useful in higher-security areas such as creating a unique ID that functions as a password, or bearer token, or proof of knowledge, etc.
2. ZID specifies that it can be as many bits as you want in multiples of 8, and a notation suffix that says the bit count e.g. "ZID-128" means ZID with 128 bits. UUID can only be 128 bits. Thus ZID is more flexible e.g. ZID-64 is a good fit for 64-bit systems, ZID-256 is good for fulfilling requirements for 256 bits of randomness, etc. This notation suffix is akin to the SHA algorithm, which has SHA-128, SHA-256, SHA-512, etc.
3. ZID specifies lowercase for hexadecimal string representation. UUID does not specify lowercase or uppercase. Thus ZID is more-specific; ZID parsing is one step easier/faster/clearer; ZID string comparison uses exact character matching rather than case-insensitive matching. Thus ZID skips entire areas of UUID bugs that we see in practice, such as one UUID system that emits lowercase, one UUID system that emits uppercase, and an integration system that needs to do string comparisons.
4. ZID is always random. UUID has multiple algorithms, as you point out. In practice we have seen the UUID multiple algorithms cause confusion and bugs e.g. when a spec says "UUID" and the implementation uses a UUIDv4 yet the spec's intent was a UUIDv1, or vice versa. Thus ZID makes it easier to write a better spec.
5. ZID subsections all satisfy proof of randomness e.g. computational statistical analysis. UUIDv4 does not, because UUID4 uses 6 fixed bits to indicate the algorithm. Thus ZID is easier and faster to prove as random, both as a whole and also as any subsection such as by subsampling.
1. ZID specifies secure random number generation. UUIDv4 does not. Thus ZID is useful in higher-security areas such as creating a unique ID that functions as a password, or bearer token, or proof of knowledge, etc.
2. ZID specifies that it can be as many bits as you want in multiples of 8, and a notation suffix that says the bit count e.g. "ZID-128" means ZID with 128 bits. UUID can only be 128 bits. Thus ZID is more flexible e.g. ZID-64 is a good fit for 64-bit systems, ZID-256 is good for fulfilling requirements for 256 bits of randomness, etc. This notation suffix is akin to the SHA algorithm, which has SHA-128, SHA-256, SHA-512, etc.
3. ZID specifies lowercase for hexadecimal string representation. UUID does not specify lowercase or uppercase. Thus ZID is more-specific; ZID parsing is one step easier/faster/clearer; ZID string comparison uses exact character matching rather than case-insensitive matching. Thus ZID skips entire areas of UUID bugs that we see in practice, such as one UUID system that emits lowercase, one UUID system that emits uppercase, and an integration system that needs to do string comparisons.
4. ZID is always random. UUID has multiple algorithms, as you point out. In practice we have seen the UUID multiple algorithms cause confusion and bugs e.g. when a spec says "UUID" and the implementation uses a UUIDv4 yet the spec's intent was a UUIDv1, or vice versa. Thus ZID makes it easier to write a better spec.
5. ZID subsections all satisfy proof of randomness e.g. computational statistical analysis. UUIDv4 does not, because UUID4 uses 6 fixed bits to indicate the algorithm. Thus ZID is easier and faster to prove as random, both as a whole and also as any subsection such as by subsampling.