alt Hacker NewsFolders as an abstraction don't really make sense beyond documents, though.
If your music is stored in a folder hierarchy, and can, in principle, be located anywhere, how do you index it to provide a library view? How do you distinguish it from random audio files that just happen to be ID3 tagged, but which you don't want as part of your permanent music collection? How do you efficiently react to deletion events? What happens if you delete an entire artist's worth of music from your music app? Should it delete the files, or only the library entries? If it deletes files, what if (some of) that music was in a folder that didn't contain any other files? Should that folder be gone too, or should you be left with an empty folder or hierarchy? What if the folder also contained a .nfo, is it good UX if it deletes the music and just leaves the .nfo?
If the only tool you have is a computer, everything is a file. If you're a music lover and not a computer enthusiast, you tend to think about albums, artists and playlists, and that's how you want to view your music collection.
You index it with btrees just like everything else. You distinguish it by configuring which folders to watch. You react to events with inotify. You don't give your music app write permission to your library. It only needs to write its indexes and playlists. All of your other questions become irrelevant; you delete the files you mean to delete with your file manager. In practice, music is small and storage is cheap, so deleting seems like a weird use-case for an application dedicated to music. I still have files that have been migrating across computers for 25 years.