As someone who maintains a UUID library, this is definitely something that has been thought about, especially in the UUIDv6-v8 updates. But it was moved to be c

As someone who maintains a UUID library, this is definitely something that has been thought about, especially in the UUIDv6-v8 updates. But it was moved to be considered later as an extension after v6-v8 get approved fully. But all these were talked about and considered before it was punted to a later time. https://github.com/uuid6/uuid6-ietf-draft/issues/27 https://github.com/uuid6/uuid6-ietf-draft/issues/27 https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/issues/4 https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/issues/2 https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d... But there is always TypeID in the meantime which uses UUIDv7 under the hood: https://github.com/jetify-com/typeid https://github.com/jetify-com/typeid Either way, I am in favor of prefixing and using alternative encodings, but it will need some time to figure out the best route. In the mean time, there are so many alternatives. TypeID, NanoID, ULID, etc. I even made my own quick one just for giggles: https://github.com/daegalus/snowflakes https://github.com/daegalus/snowflakes