MusicHawk,
An interesting workaround, I might give that a try.
As regards the additional functionality that might 'break' other apps, I don't see why this is such an issue? What is wrong with having these solutions, and the extra data, reside purely within MC's own library data?
Surely the main purpose of MC is to do whatever it can to manage standard file types with standard fields, but then to provide additional coolness that its users can take advantage of?
I suppose the question is, are we looking for extra MC functionality, or are we trying to redefine the various standards?
Why can't MC support artist1, artist2, artist3 and so on, in a drop-down list for example? Artist1 could then exist in the file's 'artist' tag, the other artists listed for the track would simply exist within MC library data. The only problem as I see it, from a 'conceptual' point of view, is that users may get a little confused as to what data is going to be edited directly within the file and which is MC-specific data. But surely this has been the case since Media Jukebox days, where you could add data to file type that did not support it? The data worked fine within MJ, but when you used that file away from MJ the additional data simply didn't exist. Why can't different coloured field backgrounds, or a different font colour, convey the difference between tag and non-tag data?
If we allow drop-down lists for multiple artists, then couldn't an alphabetical ordering by artist even display an instance of the file for each artist listed? And couldn't the same work for genres?
To use my previous example, let's take U2 and Pavarotti performing Miss Sarajevo. I might make the decision that Artist1 is U2 and Artist2 is Pavarotti. When I order my library by artist, why can't an instance of the file appear under both U and P? If I go to edit the 'clone' entry it shouldn't be too hard to alert me to the fact that this is simply a clone entry, and ask me whether I want to continue or edit the original file instead.
I think the answer to a lot of these things might lie in divorcing ourselves from the idea of one track = one library entry, and embracing the library as a tool to access the files we want in the way we want.
I'd also imagine it wouldn't be too hard to force one track = one entry for those who are particularly wedded to the concept, but they would then not be able to use the additional functionality.