I really disagree. Just because a GUID or UUID is typically done one way doesn't mean that's the only good way to do it.

We would love to use our token instead of the UUID. In our (undereducated?) opinions, UUIDs are fossils of a past era in computing and should be completely and utterly destroyed without prejudice. However, the application for which we were generating these took both tokens and UUIDs, and would not proceed without both. (We have an open requirement against them to abandon UUIDs - we'll see when/if that happens.) So, until such a time as they abandon inferior technology, we're stuck.

Our problem was one of scope: we needed thousands of UUIDs, and we needed some way to not only keep them matched across invocations, but to automatically be added when needed, removed when no longer needed, and every single one would need to be changed when we changed versions. Without failure. Since we're sometimes adding 7 or 8 at a time, other times we're adding 100-200 at a time, and then when we change versions, we're changing all 1200+ of them, we felt that it was significantly better to use Data::UUID's 'create_from_name' approach to come up with these UUIDs, and instead come up with a way to map all relevant information, including version number, into a token which we could feed into the digest to come up with our hash.

Of course, the other problem was that the entities were purely virtual without that token, and there was/is no registrar to ensure that our use of this application did not collide with other users of the application. Not much we could do about that that I can see.