OK, this thread
seems to explain the historical development of the disk mapping.
It's quite a complicated thread to follow, but from what I understand, before v2.4 MusicBee would only organise music if it was on the same partition as the MB database and media library, and it would not move files between different drives/partitions at that point. So the drive mapping was the response to that particular problem.
I still don't quite understand why it was done like this though (ie. having to set a rule for every drive/partition before you can use organisation freely).
I can see why it is handy to be able to have different rules for different partitions as a choice if you want to set that up. But if you only have one central location where all your music ends up, but several locations where new music may land in your system/network, ready to be tagged and moved, then it seems unnecessary to have to add rules for all those locations, rather than have one rule for all locations that says 'wherever a file is right now, when I add it to my database, rename it and move it to the media library'.
Maybe it was a programming/time limitation, safety feature, or because it simply solved the problem at the time. I searched around, and couldn't find many users commenting about it, so I guess it's not important. The main thing is that I understand I'm using MusicBee correctly.
It did nearly catch me out though, as I didn't know that the music I had just 'sent to library' hadn't been organised - all the files that I'd added to the database were still sitting in the download location, and I would've deleted the folders thinking they were now empty. I only noticed they had not been moved or renamed because I absentmindedly opened one of the folders.