Random UUIDs have a version of 4, this has a version of 8.

https://www.uuidtools.com/api/decode/AF39A01C-E29D-8C4C-8072-60CEB26A82F1

So am I right thinking this is a random blob of bits being represented so with hex encoding and spacing like UUID.

Interesting to know, thanks for the info! We use our database to exchange data between different database systems - apparently one of them does not generate UUID v4 but, as you write, random HEX values represented as UUID.

Up to and including MariaDB 10.11.4 this was not a problem. Can we expect that in the future it will be possible again to store also non-v4 UUIDs or do we have to migrate the columns here to BINARY(16) to keep the existing functionalities?

Non-version 4 UUIDs are allowed, its just non-UUID that aren't:

• https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-04
• https://www.rfc-editor.org/rfc/rfc4122

The only thing currently not allowed is version 8 (or greater) variant 0.

To allow the massive growth of UUIDv7 as a index friendly standards (after we'd reorganised v1 and everything else to be index friendly) created a few holes of incompatibility that corresponded to invalid parts of the UUID standard.

So sorry to say, if you're getting just random data, and can't do an UPDATE to fix those to the UUIDv4, BINARY(16) is probably the best approach.

We'll likely won't be able to allow completely random strings as UUID again. UUID has an internal structure and depending on the version and a variant, they're stored differently. To make this storage unambiguous we had to disallow some invalid UUIDs.

Variant 0, according to Wikipedia is for backwards compatibility with the now-obsolete Apollo Network Computing System 1.5 UUID format developed around 1988

Version 8 is present in the new ietf draft published on June 2022. They cannot possibly coexist in any valid UUID,