I actually used it as a desktop OS in the early 00s, it was a very relaxing experience. It was years behind FreeBSD (which was years behind Linux, which was years behind Windows...) in terms of device drivers, but it was incredibly stable, minimal, beautifully documented and well-organized OS that was a joy to work with.
As an example of what "stable" means here: OpenBSD has a port collection, but it's an implementation detail that you're not supposed to use. Instead, when a release is created, all ports are built and tested to guarantee that they work. Then, they're not updated. Ever. You're supposed to upgrade to the next release yourself, and if you don't, all the packages available to you right now will be available and working the same way 20 years from now.
(Of course, there is a -current version you can use to get more liberal update policy.)
I don't remember all the details, but it sounds like it would fit your requirements very well.
I may have to try it then. How does OpenBSD name drives? Logically, like A:\ & B:\ for floppies or removable media, C:\ for main HDD, D:\ for main optical media or second HDD, E:\ for second optical media, etc? Or does it name in the incomprehensible method Unix & Linux use that have no application to what I'm trying to do with my life?
Physical devices are named based on the driver used. Floppy is fd0 (fd1, fd2, etc. if you have more than one), cd drive is cd0 (cd1, etc.). These are generic drivers, with hard disks it gets more specific - for example, a Western Digital disk would be called wd0.
These physical devices are "mounted" into a single logical filesystem hierarchy, starting at /, with user data in /home/<username>/ (vs. C:\Users\<username>\). Various disks (and partitions) can be mounted basically anywhere in the filesystem, under any name you choose. You can mount your floppy as /A, your CD as /D and your other disk as /G and the OS won't complain at all. Traditional location for that is /mnt (ie. /mnt/G), but it's just a convention you don't have to follow.
You can learn about all the other places in the filesystem, basically what goes where, in `man hier`[1] It's like reading about the internal organization of C:\Windows, though, and can be ignored for the most part: normally, you stick to your home directory for everything and can organize it any way you like. Some desktop environments will create (and display in a special way) a more traditional set of folders, Documents, Downloads, Music and so on, but they will all be inside your home directory. You can mount your other drive (or a part of it) as your Music folder if you want, too.
As a side note, I'm not sure I would call Windows naming convention logical. It's just what you're used to. A single filesystem for everything vs. a separate filesystem for every disk/media is really a minor difference, just like the different path separator (\ vs. /) is irritating for the first week and then you stop thinking about it.
A warning, though. OpenBSD is not a desktop-oriented or newbie friendly OS. It's meant for servers and power users. There's very little hand-holding - even the installer has no GUI at all, not even console-based, it's just a command line where you type responses to printed questions. The primary interface to everything is the command line. The OS is focused on security and stability, not convenience. That being said, the system is incredibly well-documented and discoverable, and the community is very nice and welcoming, so it's not hopeless; just be aware that you're going to struggle for quite a number of hours before you make it work exactly the way you want it. The upside is that when you finally make it, it will stay that way. Forever.
I actually used it as a desktop OS in the early 00s, it was a very relaxing experience. It was years behind FreeBSD (which was years behind Linux, which was years behind Windows...) in terms of device drivers, but it was incredibly stable, minimal, beautifully documented and well-organized OS that was a joy to work with.
As an example of what "stable" means here: OpenBSD has a port collection, but it's an implementation detail that you're not supposed to use. Instead, when a release is created, all ports are built and tested to guarantee that they work. Then, they're not updated. Ever. You're supposed to upgrade to the next release yourself, and if you don't, all the packages available to you right now will be available and working the same way 20 years from now.
(Of course, there is a -current version you can use to get more liberal update policy.)
I don't remember all the details, but it sounds like it would fit your requirements very well.