Slightly less trivially, anything qemu-img handles should probably be considered at least in the neutral direction, if not actually neutral.
However it's not always the case that you can just raw copy with dd some OS and expect it to function. OS integrate with hardware and installation can produce a unique binary OS specialized for that hardware. If you can magically dd an OS or swap an OS disk from machine to machine, then it's because of OS and kernel dev magic and can cause problems down the line.
In reality the best solution in my experience is to deploy an installation process, which usually is provided by the Host provider directly, and then run my own installation steps on userspace.
The fact that this process might be slower or involve human steps is more often a feature than a bug, and it's not something that can be solved by containers (someone has to fire up the host VMs when there's too many containers too). You can always use providers that automate new vm and even hardware deployments like AWS if you really need intra-day deployments.
No, and that's not the context here.
> The standard would be BIOS/UEFI, and Partition schemas like GPT/MBR in that case.
I think the trick of wedging an MBR into the first sector of an ext2 partition with extlinux as a bootloader should still work. You really don't need much.