> This was met with “please don’t write your own UUID implementation; use a library.”

I agree with this one and I’d push back on it too.

In my experience, what will happen is you write your own UUIDv7 implementation because the language or stdlib doesn’t support it yet. Then the language eventually supports it, but this project is still using your homegrown implementation that is slightly different than the language’s implementation in an incompatible way. Lots of code is bound to your custom implementation and now it would be too much effort or cost to swap out your custom implementation for the standard one.

So now this project has a caveat: yes, it uses UUIDv7 but not the official UUIDv7 implementation, and you have to work around this land mine for the rest of the life of the project. All of these small “innocent” caveats like this add up and make working in projects like this a miserable experience.

The point of using a standard is that it is a standard, two uuidv7 libraries should not be incompatible outside of maybe things like clock resolution

That’s a fair point, but it’s also not a complex class, and could be extended to be compatible, such that swapping out for stdlib is a single import statement.

For larger or more complex problems, especially those that don’t have an RFC behind them, I can definitely see the unwillingness to do so.