Earlier quoted context omitted.
If this was anticipated by the architecture: * My USB webcams wouldn't show up in a different order each time I reboot. This works fine under Windows and Mac. * My monitor configuration wouldn't be hardcoded in my xorg config file, or swapped around manually with xrandr. I'd have a way to code up config options for whatever is plugged in, and if something unanticipated happens, it'd do something reasonable until I co…
You've described need for UUID but then discard it for disks, why? $ ls /dev/disk/by-uuid/ 266c945c-1c6d-40e7-b770-73864a5541fa $ cat /etc/fstab UUID=266c945c-1c6d-40e7-b770-73864a5541fa /
1) https://www.raspberrypi.org/documentation/installation/insta...
2) man fdisk
3) man mkfs
And so on. The /dev/sd_ is primary, with UUIDs as kind of an afterthought
It ought to be the other way around, with UUIDs as the primary, proper, canonical name and interface, and a legacy backwards-compatibility layer for /dev/sd_ devices. It's even reflected in the directory structure. Yes, I CAN list disk "by-uuid," label, id, partuuid, or path, but those are special cases with sd_ as canonical.
It's kinda retrokludged in there. I never said USB/etc. didn't work. Just that it wasn't architected for it.