> This is because NewV7 assumes that the wallclock timer always has microsecond or nanosecond precision, though a browser's wallclock (new Date.getTime()) is millisecond precision.

That's true of Date, but not Temporal, which supported in most cases. [1]

There needs to be a fallback, but when supported `Temporal.Now.instant()` is the solution.

[1] https://caniuse.com/?search=temporal

> I was gonna close this as wont fix, works as designed

Missing the forest for the trees

This sort of thing has always been tricky. There are a number of issues at play here:

* (Mentioned in the bug report) clock resolution may not be precise enough for that part of the timestamp on some platforms.

* Counters are hard to get right, especially if multiple processes may be calling this language library function and using the UUIDs side by side somewhere. So the implementation is sidestepping the whole problem of counters by not using them.

Alas, the fix for the problem only does the GOOS == "js" test when filling in rand_a. Unfortunately, it then checks for timestamp uniqueness always using rand_a as part of the timestamp value, which is not correct. The fix needs a little more work to not end up taking the extra 12 bits of random data as part of the timestamp, and potentially incrementing them, when the timestamp only has millisecond precision.