Note: groups.io will be down for maintenance on Wednesday, October 5th, starting at 9AM Pacific Time (4PM Wednesday October 5, 2022 UTC), for approximately one hour.
(I'm responding through the groups.io webui because it's way too late for a full email fetch now. So the threading & quoting will most likely be broken. Sorry about that.)
The "--initrd-inject" and "--extra-args" options are very relevant in this case. (And yes they do justify using --location.) The idea is that "--initrd-inject" modifies the temporary copy of the initrd that was copied out of the ISO (which was mounted as a local directory containing a distro install tree). "--initrd-inject" then adds the "guest-31156337-ks.cfg" file to the root of the initrd.
The "--extra-args" option goes with it. It creates an "-append" option on the QEMU command line. It tells the kernel [*] to look for a kickstart file by the name of "guest-31156337-ks.cfg" in the initial ramdisk.
[*] More precisely, the guest kernel doesn't care about "ks=..."; it's the user-space installer program (Anaconda), launched from the initrd by the kernel, that consumes "ks=..." from the kernel command line.
So these virt-install options are actually crucial (and so are the contents of the kickstart file), because they tell the guest installer what to do, after OVMF launches the guest kernel.
What devices OVMF connects in the BDS phase (that is, before ExitBootServices()), should be irrelevant wrt. how Anaconda locates a kickstart file in the initial ramdisk, and how Anaconda processes the looked-up kickstart file.
So with the new information available, I agree that "--location" is needed, because you, indeed, do *not* want a "UEFI CD-ROM boot". Instead you want a direct kernel boot, with a kickstart file injected into the initrd from the host side. However, I think OVMF's current code still does the right thing in that case, because the UEFI drivers that may or may not have connected e.g. a SATA device in the BDS phase should be totally irrelevant after ExitBootServices(). And Anaconda runs (and consumes the kickstart file) way after ExitBootServices(). The set of devices that were connected under UEFI could play a role for the kernel's UEFI stub, yes, but I don't think the kernel's UEFI stub plays any role in the installation you're trying to perform.
I'd suggest looking into the kernel log, the systemd log, and the installer logs, produced in the guest. From the log you pasted before ("Entering emergency mode. Exit the shell to continue."), it seems like the initrd is broken, and Anaconda cannot be started. This kind of error message is usually printed when the root filesystem is busted, and the kernel cannot "switch root" from the initrd to the on-disk root filesystem.
Regarding why it seems to work when you reorder PlatformBdsConnectSequence() vs. TryRunningQemuKernel() -- I have no idea. In that case, is your kickstart file really correctly processed by Anaconda?
I could imagine a (virtual) hardware problem -- assuming the firmware SATA driver doesn't ever initialize the hardware, the kernel driver could fail to access the disk, or some such... But that would require either QEMU's device model or the kernel's driver to be horribly broken. Do you see identical behavior if you use virtio-scsi?