I agree, but also, I don't see any valid reason for MC to delete files from playlists automatically. We could just get a visual indication like in the case when the physical files are missing.
I think the root of the problem from a programming perspective is that the playlists do not reference the media files themselves, but instead reference the File
Objects in the database. This concept provides all sorts of benefits, obviously. MC is a database driven application founded on the concept of abstracting the media files away from their disk files and into a system of "objects" that can be manipulated in a variety of ways separately from the file system.
The problem is that if you "delete" a file in MC (remove it from the Library), it actually deletes that file's object in the database. So all references to it are removed, including those in the playlists.
Now, for many users, this isn't a serious problem. One of the major reasons I USE MC is that I NEVER want to actually manage my files manually on disk by hand. If I need to move files, I move them within MC. The metadata stored in MC's library is way too important to break by moving them elsewhere or manipulating them externally. If I do need to manipulate them externally, there are plenty of ways to do this without deleting the file object in MC. For example, if you replace some MP3 files on disk with FLAC versions, it is a simple matter to update the existing file objects in MC to match without deleting and re-importing the files (simply change the filename tag to point to the proper files and then do a Update Library from Tags). I wouldn't
ever want to lose the play counts and date imported and all that relevant metadata that would be lost by simply re-importing them. So, doing it that way isn't something I'd ever even consider as an option, except in extreme circumstances.
However... If you are coming from a "WinAmp" perspective, where playlists are actual text files with a list of paths to files on disk, then I can see how you might not expect it to work this way! The problem is that for MC to work around this, it would have to never really delete
anything from the database, because those file object references might exist in a playlist somewhere. At the very least it would need to check each file removal operation against
all of the Playlists in the Library and then selectively remove some of them and keep others (and there could be hundreds or thousands of playlists to check and thousands of files to delete). And then there is the problem of display... If those objects were deleted from the "library" but still kept in the "database" because they were in some playlists, then MC would have to have some way to filter them out of all the "normal" file list views, but not the Playlists.
This would quickly become ungainly and unworkable. The database would be ballooning in size because of these "phantom" file objects, many of which you might not actually want anymore because they are sitting in an obscure playlist filed in a playlist group that you haven't considered or looked at in months or years. You'd be left with a situation where the database might need to track hundreds or thousands of these phantom file objects for no good reason.
I'm not suggesting that it isn't an issue for some use-cases, but it
is a tough problem, not a simple "why can't it just keep listing them" type of solution. I've certainly run into similar problems in the past, and I've lost some very valuable playlists because of it (including one I really wish I still had). I have, however, developed some strategies to prevent it from ever happening again:
1. I
never manage file locations for files on my "media drive" outside of MC. Period. Exclamation point. It just isn't an option. Like I mentioned above, there are tons of ways to manage things from within MC that won't break your file object links in the database, and frankly, MC's tools for file system management are much more powerful than anything Windows Explorer provides.
2.
Every single file in my main media drive storage system is in the MC library and managed by the MC library. This includes PDFs, text Files, JPGs... Everything. Nothing is in those folders that MC doesn't know about and manage.
3. If I have a particularly valuable playlist, such as the manually-built list I used for my wedding music, I export that playlist to disk any time a change is made. I have a simple M:\Playlists\ folder on disk where I store these. I don't actually use them for anything real, except as a backstop. Exporting playlists to simple M3U files can be a lifesaver if you need to ever manually rebuild an essential and finely-crafted playlist by hand if something catastrophic happens that breaks rules 1 & 2.