The current implementation[1][2] works well for a typical FreeBSD target triplet (version number is between 0..255), but falls flat for any other BSD-based distribution (and maybe NT).
1. OpenBSD (i.e: powerpc64le-openbsd6.9)
Every OpenBSD release is a major release, so the parsed version number should perhaps be `69` instead of `6`.
See: https://www.openbsd.org/plus.html
2. NetBSD (i.e: armv7-netbsd9.1)
NetBSD 9.0 is the 17th major release (other 9.x are feature releases), so they obviously haven't always been following the convention of the first digit meaning the major version number, but then again, probably no one will be running NetBSD 1.5 any more, so this is just an observation.
See: https://netbsd.org/releases/formal-9/
3. Solaris (i.e: sparcv9-solaris2.11)
The '2' in solaris2 is not the major version number of the OS, rather it's a legacy marker that came about by the jump from Solaris 2.6 to Solaris 7 - the version triplet remained as solaris2.7 however. So it is in the minor version position that should determine what osMajor is set to.
4. MacOS (i.e: aarch64-darwin21)
There is no correlation between the darwin number and OSX version number (i.e: darwin18 is 10.14, darwin19 is 10.15, darwin20 is 11.0, darwin21 is 12.0). So there may have to be some sort of associative array. However it's likely better to just ignore the darwin version number and allow users to specify the (minimum) version they wish to support via another mechanism.
Similarly, version numbers in the __MAC_XX_YY macros use a six digit version numbering scheme which would overflow a `ubyte` anyway i.e: 100500 (10.5), 101500 (10.15), 110000 (11.0).
5. Windows (i.e: x86_64-windows2015)
I have no idea what versioning scheme Windows uses, but using a year was accepted as valid by clang, and that would obviously overflow the ubyte field.
[1]: https://github.com/dlang/dmd/blob/943abe37fa475099714f3c652a8b64ea2cb40272/src/dmd/target.d#L110
[2]: https://github.com/dlang/dmd/blob/943abe37fa475099714f3c652a8b64ea2cb40272/src/dmd/target.d#L1631-L1638