I’d assume the validation is parsing the uuid with a uuid library (to decode it), and the library eagerly validates the version field, either to check for garbage or because it wants to yield a different subtype for each version.
- if the ID is intended to be opaque then the vendor shouldn't document it as a UUID, as this changing to a different format would be a breaking change
- if the customer isn't going to process the subcomponents of the UUID then they should process it as an opaque string
- if the UUID library encounters a version number in a UUID it doesn't understand, it shouldn't reject the UUID but present it as an unstructured string.
After this blog post it seems likely that even Kite more customer will parse the IDs to extract time, since this has been documented.
Probably because a typed UUID avoids treating it like a random string, and decoding the UUID means you have 16 bytes per in memory rather than 36 (assuming usual 8-4-4-4-12 representation over the wire).
