I was looking into AVX10, and noticed that GCC and LLVM both use the evex512 feature to sort of turn on avx10. If avx512 or avx10.N-512 is enabled, this flag is turned on, but not for avx10.N-256. So now, if one wants a function that uses avx512f with a 512-bit type, they will use both the avx512f and evex512 attributes, but if it uses only 256-bit types, they will use avx512f and no-evex512. In rust, we don't have evex512, instead it is automatically enabled if any avx512 feature is enabled. This makes avx10.N-256 impossible to implement because these use avx512 instructions that use 256-bit vectors.
If we add the evex512 target feature attribute, fix the stdlib and remove the backend glue, this would create a massive incompatibility in many projects. Although avx512 is technically unstable, it is heavily used by the community. GCC and CLANG also faced this problem, and they decided to enable evex512 by default, which could be overridden by no-evex512. The problem with this approach is that rust doesn't have negative target features.