I have something even more complex (ignore p3 and p4, an old dual boot)

❯ lsblk /dev/nvme0n1
NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1         259:0    0 931.5G  0 disk  
├─nvme0n1p1     259:1    0     2G  0 part  /boot
├─nvme0n1p2     259:2    0 729.5G  0 part  
│ └─enc         254:0    0 729.5G  0 crypt 
│   ├─pool-swap 254:1    0    64G  0 lvm   [SWAP]
│   └─pool-root 254:2    0 665.5G  0 lvm   /mnt
│                                          /home
│                                          ...
│                                          /
├─nvme0n1p3     259:3    0     4G  0 part  
└─nvme0n1p4     259:4    0   196G  0 part

this is really more telling, i guess:

➜ sudo parted /dev/nvme0n1 print
Model: DOES-NOT-MATTER (nvme)
Disk /dev/nvme0n1: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  2000GB  2000GB               primary
 2      2000GB  2000GB  512MB   fat32        ESP      boot, esp

disko configuration that i wrote recently but haven't used to reformat my in-use disk (because i haven't bothered migrating) is:

let
  # mkSubvolumes is a helper function to define BTRFS subvolumes from a list
  # of strings (representing the path the subvolume will be mounted at, and
  # using that as the name)
  mkSubvolumes = paths: builtins.listToAttrs (map (p: {
    name = p;
    value = {
      mountpoint = if p == "/root" then "/" else p;
      mountOptions = [ "defaults" "ssd" "compress=zstd:3" "noatime" ];
    };
  }) paths);
in
{
  disko.devices = {
    system = {
      device = "/dev/disk/by-id/...";
      type = "disk";

      content = {
        type = "gpt";

        partitions = {
          ESP = {
            size = "1024M";
            type = "EF00";
            content = {
              type = "filesystem";
              format = "vfat";
              mountpoint = "/boot";
              mountOptions = [ "umask=0077" ];
            };
          };

          luks = {
            size = "100%";
            content.type = "luks";
            content.name = "system";
            content.settings.allowDiscards = true;

            # use a fido2 key for unlocking
            content.enrollFido2 = true;

            # do not generate a recovery passphrase (i manually add additional fido keys)
            content.enrollRecovery = false;

            content.content = {
              type = "btrfs";

              subvolumes = mkSubvolumes [
                "/nix"
                "/persist"
                "/root"
                "/var/log"
                "/home"
              ] // {
                "/swap" = {
                  mountpoint = "/swap";
                  swap.swapfile.size = "72G";
                  swap.swapfile.path = "file"; # relative path, results in /swap/file
                };
              };

              # This hook creates a snapshot of the root subvolume after it is
              # created (and critically, empty), which is used for automatic
              # rollback on startup. see //system/modules:impermanence.nix for
              # more information about that process.
              postCreateHook = ''
                set -eufo pipefail
                MOUNTPOINT=$(mktemp -d)
                mount --type btrfs \
                  --options defaults,ssd,noatime,subvol=/ \
                  /dev/mapper/system \
                  "$MOUNTPOINT"
                trap 'umount "$MOUNTPOINT"; rm -rf "$MOUNTPOINT"' EXIT
                btrfs subvolume snapshot -r \
                  "$MOUNTPOINT/root" "$MOUNTPOINT/root-blank"
              '';
            };
          };
        };
      };
    };
  };
}

you can also do this using btrfs native multi-disk support

this is how i'll be migrating this machine's disk to a new disk, with the above disko configuration. btrfs send :)

my impermanence module (referenced in the above config) just sets up the boot.initrd.systemd.services.rollback unit that handles deleting the root subvol and rolling back from the snapshot, and contains my environment.persistence."/persist" configuration (and other stuff necessary to handle w/ impermanence.

i'd be interested in seeing your crash recovery setup.

my impermanence module (referenced in the above config) just sets up the boot.initrd.systemd.services.rollback unit that handles deleting the root subvol and rolling back from the snapshot, and contains my environment.persistence."/persist" configuration, and other stuff necessary to handle w/ impermanence.

i'd be interested in seeing your crash recovery setup.

my impermanence module (referenced in the above config) just sets up the boot.initrd.systemd.services.rollback unit that handles deleting the root subvol and rolling back from the snapshot, contains my environment.persistence."/persist" configuration, and other stuff necessary to handle w/ impermanence.

i'd be interested in seeing your crash recovery setup.