Digging deeper and walking through this in a focal vm, I'm seeing some strange things.

Starting with a clean disk, and just creating the backing device like so:

make-bcache -B /dev/vdb

We see /dev/bcache0 get created with vdb as the backing device.  Now, after this, I see:

/dev/bcache/by-uuid/<dev.uuid> -> ../../bcache0

This is unexpected.  It should *only* appear once the bcache0 device is actively cached;  that is the bcache driver should not emit CACHED_UUID, until the UUID is actually cached, which only happens once we've registered a cache device with the bcache0 device.  We need to look at the kernel source to see if the SAUCE patch isn't quite right, or some other part of bcache code has changed.

Next issue, blkid now detects the bcache dev.uuid, and this shows up like so:

# udevadm test-builtin blkid /sys/class/block/vdb
...
vdb: Probe /dev/vdb with raid and offset=0
ID_FS_UUID=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
ID_FS_UUID_ENC=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
ID_FS_TYPE=bcache
ID_FS_USAGE=other

Note, it shows up as an FS_UUID, but it is *NOT* an fs_uuid; there is no filesystem on this device at all at this time;  it does have a bcache superblock, note the FS_UUID matches the dev.uuid of the backing device.

# bcache-super-show /dev/vdb
sb.magic		ok
sb.first_sector		8 [match]
sb.csum			29D6774A332A280B [match]
sb.version		1 [backing device]

dev.label		(empty)
dev.uuid		d7d7e025-b8d2-43cb-a5df-c240ba1418dc
dev.sectors_per_block	1
dev.sectors_per_bucket	1024
dev.data.first_sector	16
dev.data.cache_mode	0 [writethrough]
dev.data.cache_state	0 [detached]

cset.uuid		37b37bc1-e185-4825-8900-579df102b7d6

It's also curious that cset.uuid has a UUID, as there are no csets created; IMO this is also a bug and it should be 0, null, or empty.

Now, here's where the udev fights over the links.  The backing device, vdb, triggers this rule in 60-persistent-storage.rules:

# by-label/by-uuid links (filesystem metadata)
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"

This creates confusion due to the CACHED_UUID also being emitted from the kernel, like so:

root@ubuntu:/run/udev/links# ls -al /dev/disk/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc 
lrwxrwxrwx 1 root root 9 May 21 16:39 /dev/disk/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc -> ../../vdb
root@ubuntu:/run/udev/links# ls -al /dev/bcache/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc
lrwxrwxrwx 1 root root 13 May 21 16:39 /dev/bcache/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc -> ../../bcache0

There we have two devices both claiming the backing devices dev.uuid value, with two different block names.

So, in summary, there are two problems to fix:

1) blkid on bcache devices should not report FS_UUID values when FS_TYPE=bcache; there is no filesystem on it; this will need to be discussed upstream

2) our kernel (need to check mainline vs. ours) emits CACHED_UUID when the bcache0 is created, but no cache is attached:  see this udev event:

KERNEL[2217.605118] change   /devices/virtual/block/bcache0 (block)
ACTION=change
DEVPATH=/devices/virtual/block/bcache0
SUBSYSTEM=block
DRIVER=bcache
CACHED_UUID=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
CACHED_LABEL=
DEVNAME=/dev/bcache0
DEVTYPE=disk
SEQNUM=5890
MAJOR=251
MINOR=0