They don't, really. The Windows NT kernel has a unified namespace — it's just not one with a filesystem at its root, but rather an object namespace, so users (and even developers) are almost never exposed to it.
C:\ is just win32.dll-wrapper-ese for the NT object path \\?\Volume{some-guid}\, where \\? is the NT object (local) namespace root. You can find the GUID of your filesystem in diskmgmt.msc and navigate Explorer to \\?\Volume{some-guid}\ just fine. Look ma, no drive letters!
Perhaps surprisingly, despite \\?\Volume{some-guid} being the name of a Volume object, what you find under \\?\Volume{some-guid}\ is a regular filesystem of Directory and File objects.
It's as if Linux was set up such that / was a hybrid of procfs+sysfs+devfs, and all the filesystems were accessed by going to /dev/disk/by-uuid/... and navigating "into" one of the block-device nodes there.
I use storage spaces on Windows 10 on 1 machine with 2 drives to mirror them.. so basically a software raid. It's pretty interesting and it just works, I don't have to babysit it. Same with Zfs mirroring. Wonder by how much these two software mirroring techniques differ from each other.
Genuine question, trying to imagine how/why I would not want drive letters. Maybe each device should just use the uuid set by the manufacturer? But then that's too ugly to display in a file explorer.. and often I don't just have 1 partition per physical device, so multiple mount points.. and other times I have 1 mount point with multiple backing devices (mirrors/raid).