WetGeek It appears we have different goals here.
I don't have any goals at all for your installation, nor are we at cross purposes, nor am I questioning anything you did or questioning why you did what you did. I'm sorry if I gave you a different impression. My inquisitive nature sometimes gets in the way of communication.
WetGeek I was simply surprised that it offered the option to change the installed and running version from BIOS to UEFI, so I noted that. I'd never seen a distro offer that before.
I'm surprised that a distro that goes to such lengths to stress the importance of UEFI installation ("configure your device to use UEFI only in its setup utility" ... "We recommend to boot the drive in UEFI mode if listed." and so on) would install to BIOS by default under any circumstances when UEFI is enabled. That's what seems to have happened in your installation.
Solus doesn't behave that way. If Solus sees that UEFI is set, even when BIOS/CSM is enabled, Solus installs to UEFI rather than BIOS. I think that is probably true of most distros, but I have never installed anything Arch before, so I don't know if Arch behaves differently in that respect from Ubuntu-derivatives, Solus or openSUSE.
My guess is that installing into a VM rather than bare metal may have triggered the problem, that by installing into a VM Gaurda's safeguards were somehow disabled.
So I'm curious about how Garuda handles the issue in a bare metal installation, and I'll test tomorrow. I'll set my test computer to UEFI but enable BIOS/CSM, which is currently disabled. My guess is that Garuda will install as according to the installation instructions with UEFI set and BIOS/CSM enabled, recognizing that it could install into either UEFI or BIOS, and offering a choice at the beginning of the installation process. That's what the documentation says that Garuda does, and I want to check for myself.
Whatever the outcome, I'll keep this rabbit hole to myself and not post further about the issue.