I’m not sure of the state of that particular library, but yes, the RFC has changed significantly. For instance, the UUIDv7 format changed from the earlier draft RFC resulting in incompatibilities.

This is an example of an unmaintained UUID library in a similar situation that is currently causing incompatibilities because they implemented the draft spec. and didn’t update when the RFC changed:

https://github.com/stevesimmons/uuid7/issues/1

Any Python developer using the uuid7 library is getting something that is incompatible with the UUIDv7 specification and other UUIDv7 implementations as a result. Developers who use the stdlib uuid package in Python 3.14+ and uuid7 as a fallback in older versions are getting different, incompatible behaviour depending upon which version of Python they are running.

This can manifest itself as a developer using UUIDv7 for its time-ordered property, deploying with Python <=3.13, upgrading to Python 3.14+ and discovering that all their data created with Python 3.13 sorts incorrectly when mixed with data created with Python 3.14+.

A UUID library that is not receiving updates is quite possibly badly broken and definitely warrants suspicion and closer inspection.

RFC changes aside, the go community has been bit by unmaintained UUID libraries with security issues. Consider https://github.com/satori/go.uuid/issues/123 as a popular example.

The open issue in Google's repo about the package being malicious is not a good look. The community concluded it's a false positive. If the repo was maintained they'd confirm this and close the issue.

Maintaince is much more than RFC compliance, although the project hasn't met that bar either.