Okay, so here's what snapd currently does:

1) we mount the partition that we think the kernel booted from somewhere (w/ uefi we know this exactly and can use the partition uuid that uefi var that shim writes to, w/o uefi var, we just guess and use `/dev/disk/by-label/ubuntu-boot`)

2) after that is mounted somewhere, we look back at what disk that was mounted from using mountinfo table.
2a) Specifically we parse /proc/self/mountinfo, and whatever entry is last in that table and has a mount destination matching /run/mnt/ubuntu-boot, we get the mountpoint source, and then query udev with `udevadm info --query property --name /dev/mmcblk0p16`. 
2b) If we expect the device to be unencrypted, as is the case with ubuntu-boot, we grab ID_PART_ENTRY_DISK, and save that major/minor pair as the disk that this partition comes from.
2c) If we expect the device to be a mapper / decrypted device, as is the case with ubuntu-data in FDE, we instead read `/sys/dev/block/$MAJOR:$MINOR/dm/uuid` (where major/minor come from the mountinfo table entry we got in step 2a) and `/sys/dev/block/$MAJOR:$MINOR/dm/name`, then we do some manipulation of the uuid/name values we got to build up the partition uuid that matches the luks uuid pattern, which then we can use with /dev/disk/by-uuid to find the underlying, physical, encrypted partition for that decrypted mountpoint. We then query udev properties for that encrypted partition, and use ID_PART_ENTRY_DISK from that encrypted partition the same as we did in the unencrypted case in 2b.

3) With this all in hand, we know what disk the mountpoint we mounted came from, and now we want to find partitions with specific labels that come from the same disk as the one we just mounted, i.e. after mounting ubuntu-boot, then we want to mount ubuntu-seed. So to do this, we now build up a mapping of disk major/minor -> partitions by iterating through the devices with the same major number as the disk, but with increasing minor numbers starting with the disk minor itself +1, and assume that all adjacent major/minors are from the same disk (which is an INCORRECT assumption as we now know). We stop looking once we either don't find any more devices with the same major number, or we hit a device that is not a partition. To be specific, the pseudo code is something like this:

childPartitions = {}
devMinor := diskMinor
for true:
    devMinor++
    udevProps, err := $(udevadm info --query property --name /dev/block/$diskMajor:$devMinor)
    if err != nil 
        break
    if udevProps["DEVTYPE"] != "partition"
        break
    if udevProps["ID_FS_LABEL_ENC"] == ""
        continue
    if udevProps["ID_PART_ENTRY_UUID"] == ""
        return err("broken")
    childPartitions[ udevProps["ID_FS_LABEL_ENC"] ] = udevProps["ID_PART_ENTRY_UUID"]


and then afterwards we check if the desired filesystem label of ubuntu-seed, etc. is inside the map childPartitions, and if it is we mount that partition uuid, otherwise we fail.

Hopefully that helps understand what snapd currently does. 

I had a look at the udev database from the dragonboard in question that prompted this problem, and came up with this psuedo code replacement for step 3 (as step 2 currently doesn't care about sequential/adjacent devices, and is robust against this already even for encrypted devices):

udevProps, err := $(udevadm info --query property --name /dev/block/$diskMajor:$devMinor)
if err != nil 
   return err("broken")

diskDevName = filepath.Base(udevProps["DEVNAME"])
diskDevPath = udevProps["DEVPATH"]

childPartitions = {}
paths := glob("/sys" + diskDevPath + "/" + diskDevPath + "*")
for path in paths:
    partitionFile = readFile(path + "/partition")
    if partitionFile == "1":
        ueventFile = readFile(path + "/uevent")
        partitionMajor = ueventFile["MAJOR"]
        partitionMinor = ueventFile["MINOR"]
        udevProps := $(udevadm info --query property --name /dev/block/$partitionMajor:$partitionMinor)
        childPartitions[ udevProps["ID_FS_LABEL_ENC"] ] = udevProps["ID_PART_ENTRY_UUID"]


Essentially what this is doing is globbing /sys/dev/platform/many/other/paths/mmcblk0/mmcblk0*, and then picking those matching devices which are partitions, and reading the udev info for the matching partitions. 

Please let me know if this is flawed in some way, I will try to code this up in snapd and test it out on the following devices:

* this dragonboard which has non-adjacent devices for it's internal mmc
* my pi which will use a mbr scheme for an SD card
* an x86 vm with encryption
* an x86 vm w/o encryption