Yes the boot order is described in RPFs docs in github, the SD is always scanned first.
The boot process scans volumes for a VFAT partition with boot.bin and other binaries in it.
I’ve read somewhere that the bootable partition doesn’t need to be in 1st position in the table anymore, I couldn’t confirm that.
The scan operates volume by volume. If you have 2 VFAT partitions on a volume, first one fake and 2nd one real, the 1st one gets tested and although it doesn’t allow booting the 2nd one is not tested. Instead the next volume is scanned.
To stop booting from the SD when the SD is inserted, I’ve confirmed a “suicide” option is possible, where the running OS alters /boot so that it won’t be selected on next reboot.
I don’t remember details, I think I renamed boot.bin to boot.hidden and that was that.
I remember trying to change the FS type label for the boot partition (from fat16 to “hidden Fat16” or something like that) but that did not produce the expected effect, the partition is still tested and used if possible.
Deleting the partition is a possibility but that’s a bit radical and IIRC a rename was enough.
Obviously when you do that there is no going back, and if the system fails to reboot via USB or network, your Pi is dead in the water.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel