Another weird oddity: I am not sure that the GPT formatter is respecting the device paths. When running the test VM against the mdadm config, I would have assumed it would fail since the example file doesn't have a valid device path. (/dev/my-drive) Checking the logs, it just looks like it picks the next disk in the sequence:

machine # [   62.117159]  vdb: vdb1 vdb2
machine # [   62.244857] systemd[1]: Finished Virtual Console Setup.
machine # [   63.165182]  vdb: vdb1 vdb2
machine # + partprobe /dev/vdb
machine # + udevadm trigger --subsystem-match=block
machine # + udevadm settle
machine # + device=/dev/disk/by-partlabel/disk-disk1-mdadm
machine # + name=raid1
machine # + type=mdraid
machine # + echo /dev/disk/by-partlabel/disk-disk1-mdadm
machine # + cat /tmp/tmp.Z9w0tCq6Ai/raid_raid1
machine # + device=/dev/vdc
machine # + imageName=disk2
machine # + imageSize=2G
machine # + name=disk2
machine # + type=disk
machine # + device=/dev/vdc
machine # + efiGptPartitionFirst=1
machine # + type=gpt
machine # + blkid /dev/vdc
machine # /dev/vdc: PTUUID="c27c8535-3a4b-4d3d-99a6-bd5b541b52a1" PTTYPE="gpt"

{
  disko.devices = {
    disk = {
      disk1 = {
        type = "disk";
        device = "/dev/my-disk";
        content = {
          type = "gpt";
          partitions = {
            boot = {
              size = "1M";
              type = "EF02"; # for grub MBR
            };
            mdadm = {
              size = "100%";
              content = {
                type = "mdraid";
                name = "raid1";
              };
            };
          };
        };
      };
      disk2 = {
        type = "disk";
        device = "/dev/my-disk2";
        content = {
          type = "gpt";
          partitions = {
            boot = {
              size = "1M";
              type = "EF02"; # for grub MBR
            };
            mdadm = {
              size = "100%";
              content = {
                type = "mdraid";
                name = "raid1";
              };
            };
          };
        };
      };
    };
    mdadm = {
      raid1 = {
        type = "mdadm";
        level = 1;
        content = {
          type = "gpt";
          partitions = {
            primary = {
              size = "100%";
              content = {
                type = "filesystem";
                format = "ext4";
                mountpoint = "/";
              };
            };
          };
        };
      };
    };
  };
}

I tested this by changing the path to /dev/disk/by-path/virtio-pci-0000:00:0a.0 which maps to
lrwxrwxrwx 1 root root 9 Feb 14 05:33 virtio-pci-0000:00:0a.0 -> ../../vdc
yet it completely ignores that. Maybe I am not understanding this correctly O.o

Did some more investigating, and running into an issue with sgdisk not creating the partition labels when using GPT:

sgdisk --align-end --new=1:0:-0 --partition-guid=1:R --change-name=1:disk-disk3-bcachefs --typecode=1:8300 /dev/vdd

The auto populated /dev/disk/by-partlabel/disk-disk3-bcachefs path doesn't exist. I was reading some issues on github about a potential length issue, so I reduced the names of the disks to disk1 disk2 and disk3. Still facing this issue. Any insights would be great

Did some more investigating, and running into an issue with sgdisk not creating the partition labels when using the GPT module:

sgdisk --align-end --new=1:0:-0 --partition-guid=1:R --change-name=1:disk-disk3-bcachefs --typecode=1:8300 /dev/vdd

The auto populated /dev/disk/by-partlabel/disk-disk3-bcachefs path doesn't exist. I was reading some issues on github about a potential length issue, so I reduced the names of the disks to disk1 disk2 and disk3. Still facing this issue. Any insights would be great