My understanding of baremetal development might be limited, but my preference is to land [1].
If normalizing aarch64-none-elf to aarch64-unknown-none-elf instead of aarch64-none-unknown-elf moves toward the right direction,
Let’s do it. Accruing special cases/workarounds might lead to more pain in the long term.
The number of none-unknown test changes actually looks manageable.
The worst case is that we notice some backward compatibility story that we don’t account for today,
and we add temporary workarounds for clang --target=aarch64-none-elf to probe lib/aarch64-none-unknown-elf (old LLVM_ENABLE_PER_TARGET_RUNTIME_DIR hierarchy)
beside lib/aarch64-unknown-none-elf.
The description of [1] Triple::normalize: Set OS for 3-component triple with none as middle is difficult to parse.
But from looking at the test changes, the change looks desired.
This may have to be incremental and if there is backward compatibility concern we need to account for it.
I have thought about how to support Debian-style multiarch <arch>-<os>-<env> (no <vendor>):
https://reviews.llvm.org/D110663
My conclusion is that we should use normalized target triples for runtime libraries (e.g. /tmp/Rel/lib/clang/19/lib/x86_64-unknown-linux-gnu/ /tmp/Rel/lib/x86_64-unknown-linux-gnu/) but have some probing code to support GCC installations with un-normalized triples (e.g. /usr/lib/gcc-cross/aarch64-linux-gnu/).