Note that this has been asked -and rejected- in the past, here: #23789, and here #28324.

It's not clear what concrete, tangible benefits would bringing github.com/google/uuid in the standard library give us. Third-party packages are easy to import and use, and can have a more flexible release cycle than the standard library.

Guess the strongest argument is going to be that if you have to import it externally every time, it might as well be part of the standard library in the first place.

Pretty much every other language does, and tends to include it as part of its crypto library.

UUID versions 1, 2, 3, 4, 5 are already outdated. The latest and most promising version is 7. See https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/ However, version 7 allows for many different implementation options. It is necessary to wait for the results of applying various options.

6.12. Opacity
As general guidance, it is recommend to avoid parsing UUID values unnecessarily, and instead treating UUIDs as opaquely as possible. Although application-specific concerns could of course require some degree of introspection (e.g., to examine the Section 4.1, Section 4.2 or perhaps the timestamp of a UUID), the advice here is to avoid this or other parsing unless absolutely necessary. Applications typically tend to be simpler, more interoperable, and perform better, when this advice is followed.
Sourse: https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bis-14.html#name-opacity