v1.16.7

ADDED:
* uuidx
FIXED:
* sprigx docs consistency

uuidx/doc.go

@@ -0,0 +1,73 @@
+/*
+Package uuidx intends to supplement [github.com/google/uuid].
+
+# Microsoft GUID Shenanigans
+
+The following functions are provided to deal with [Microsoft's incompetence]:
+
+	* [DetectMsGuid] (a confidence'd determination if a UUID is a Microsoft GUID or not)
+	* [IsFlippedEndian] for flipped-endian [uuid.UUID] comparison (e.g. a is the Microsoft-flipped-endian version of b)
+	* [IsMsGuid] (wraps [DetectMsGuid] and returns true if confidence is reasonably strong that it's a Microsoft GUID)
+	* [IsRfc] (the inverse of IsMsGuid, but also checks for strict RFC compliance and returns which RFC)
+	* [MsGuidToUuid] (explicitly convert/ensure a GUID/UUID is likely a UUID)
+	* [ToggleUuidMsGuid] (blindly flip the endianness of selected byte ranges for MS GUID <-> UUID conversion)
+	* [UuidToMsGuid] (explicitly convert/ensure a GUID/UUID is likely an MS GUID)
+
+Microsoft, in their typical insanity, uses a proprietary UUID format (usually referred to as the "Microsoft GUID Format"
+or "Mixed-Endian Format").
+
+Normally for, for example a UUIDv4, it's structured as thus per RFC 9562 [§ 5.4] (which obsoletes RFC 4122 [§ 4.4]):
+
+	       A               B               C               D                E
+	HEX(BE(uint32))-HEX(BE(uint16))-HEX(BE(uint16))-HEX(BE(<uint16>), BE(<6 bytes>))
+
+(where <BE> is big-endian packing).
+
+However, thanks to Microsoft we can't have nice things. They decided to completely ignore the standard, and
+instead keep D/E as big-endian *but use little-endian* for A through C inclusive:
+
+	       A               B               C               D                E
+	HEX(LE(uint32))-HEX(LE(uint16))-HEX(LE(uint16))-HEX(BE(<uint16>), BE(<6 bytes>))
+
+"Surely that had SOME reason to do that," you may say to yourself, "they wouldn't make some arbitrary formatting
+change from a standard just because."
+
+You would be wrong. To my knowledge, they have never provided any technological justfification to this insanity,
+and now it's infected its way into a slew of other technologies they've had their grubby little hands involved in
+(e.g. UEFI). And it's of course too late to change.
+
+So anyways here's a library to make dealing with Microsoft's hubris a little easier.
+
+# Validation/Verification
+
+Aside from trying to address Microsoft silliness, there are some additional functions:
+
+	* [Equal] for [uuid.UUID] comparison
+	* [IsMaxUUID] (if a given [uuid.UUID] is an RFC 9562 [§ 5.10] UUID)
+	* [IsNilUUID] (if a given [uuid.UUID] is an RFC 9562 [§ 5.9] UUID)
+	* [IsValid] (If an RFC can be considered safely conformant to RFC spec)
+
+# Future Incorporation/Deprecation/Obsolescence
+
+Worth keeping an eye on are:
+
+	* https://github.com/google/uuid/pull/192
+	* https://github.com/golang/go/issues/62026
+	* https://github.com/golang/go/issues/76319
+		(generally it's a bad idea for an API addition overall, but some good ideas were raised)
+
+Some of these additions may deprecate/obsolete components of this package.
+I'll try to keep them around but mark as deprecated as they are (if they are),
+but I make no concrete promises - I hate making new major releases in Go's
+[silly module architecture] even more than I do keeping old deprecated code around.
+So caveat emptor.
+
+[Microsoft's incompetence]: https://learn.microsoft.com/en-us/windows/win32/api/guiddef/ns-guiddef-guid
+[§ 5.4]: https://datatracker.ietf.org/doc/html/rfc9562#section-5.4
+[§ 4.4]: https://datatracker.ietf.org/doc/html/rfc4122#section-4.4
+[§ 5.9]: https://datatracker.ietf.org/doc/html/rfc9562#section-5.9
+[§ 5.10]: https://datatracker.ietf.org/doc/html/rfc9562#section-5.10
+[github:google/uuid#192]: https://github.com/google/uuid/pull/192
+[silly module architecture]: https://go.dev/doc/modules/major-version
+*/
+package uuidx