However, it is not clear from the documentations what Vector*.Clamp/ConvertToInt/Max/Min do in those cases.

It is not documented because it is hardware dependent. Given two CPUs it may have entirely different behaviors.

Vector128.MinNative for example is documented as:

Compare two vectors to determine which is lesser on a per-element basis using platform specific behavior for NaN and NegativeZero.

This covers that it picks the lesser of left vs right on a per-element basis, but the behavior of NaN and NegativeZero is platform specific. So for most values it does what you expect, but for NaN and NegativeZero it could do something different. We aren't going to document this, because we aren't going to make guarantees what a given piece of hardware will do (and often cannot guarantee this over time).

An example of this is that on Arm64 hardware it will just continue emitting fmin because this is a single instruction that already does the right thing and is the fastest single instruction. If a faster single instruction existed in the future, we might switch to that instead, provided it met the guarantees presented above (behaving correctly for all inputs that are not NaN or NegativeZero).

Alternatively, on most x64 hardware we will emit minps which will return right if either input is NaN or if both inputs are zero with opposite signs. However, on newer AVX512DQ capable hardware we have access to vrangeps which takes the same amount of time but allows you to ensure that -0 is returned if both inputs are zero with opposite signs. However, vrangeps does not allow you to have IEEE 754 compliant behavior for NaN. Rather, if one input is sNaN and the other a regular value, it will return qNaN; whileif one input is qNaN and the other a regular value, it will return the regular value. On AVX10.2 capable hardware we will get access to a new vminmaxps instruction which will let us have the IEEE 754 compliant behavior in a single instruction, assuming it is as fast as minps and vrangeps we will likely switch to it instead.

However, such behaviors aren't guaranteed. The entire purpose of the *Native functions is it is dependent on the native machine you're targeting, so we are free to change it over time provided the documented invariant is kept. It will be deterministic within a single run, but can otherwise differ in behavior for the listed edge cases.

Some of those methods like Vector128.Max are documented to match IEEE 754:2019, but the information is still missing for other methods including Vector512.Max.

This looks like it somehow got dropped from Vector64/Vector256/Vector512. It exists in the source.

@gewarren, is there an easy way to get these docs repopulated from the C# XML documentation comments to ensure remarks like this are consistent across the APIs? It looks like there might be quite a few cases like this where Vector128 has remarks or other documentation but Vector64/256/512 are missing them

The question is about the documentations of the non-native versions, not the native versions.