One option would be to hard-wire, i.e. hard link one special DB field/file tag, like an MM specific keyword field - no changes allowed. The even better solution would be to offer the user to truly customize the field, i.e. to select any single one of (a) MM's CUSTOM1-5 id3-tags or (b) a new keyword field (or even any field/tag?) as the one in the song file that MM tags its db field value to. This offers the developers the possibility to build on existing fields (in the case of CUSTOM1-5), and users to re-use / re-map CUSTOM keyword fields already in use (e.g. those using onkel_enno's script "Update Custom Fields with Pre-Selection").
In case a KEYWORDS tag in id3 would be used, it would need to be a custom one, of course. I know Matroska uses keywords, RIFF uses IKEY and iTunes/AAC has a keyw field, AFAIK.
More arguments
Of course, you already can mis-use the existing classification types and have all the functionality requested here. But firstly, it breaks my heart to mis-use classifications types/names.
Secondly, for at least some intensive use(ers) of MM, there's a good reason to use the existing classification types for their intended meaning, they are needed, important, widely used and clearly separated in their meaning. Also, this feature has been requested in some way often enough to be considered as a formal feature extension, just as a nice, clear solution. Finally, to lay out some abstract theory here: I agree with Lowlander's argument cautioning us against sometimes questionable value-added of Web2.0 social-whatever stuff, but I think there's room for some sort of unstructured, chaotic, "bottom-up" classification complementing the existing structured, hierarchical, planned, "top-down" classification existing in MM right now. Eh, I'm working on my PhD, can youl tell??
But hey, maybe this also makes some teenagers and last.fm users feel comfortable with MM 
Category:
A combination of
- UI
- Library features
- File formats / Tagging (the latter, somewhat)
Actually, the combination of the three is why this should be covered officialy by MM, IMHO. There are custom solutions for each individual aspect, but not a nice integrated solution.
There have been numerous requests and good argumentations in the wishlist forum as well as in many other subforums here over the last few years (!), so this is not new, but I think the time has come and it would be a good idea to clean things up a little.
Examples of supporting threads in this forum:
- http://www.mediamonkey.com/forum/viewto ... f=4&t=6716, 2005, 2007
- http://www.mediamonkey.com/forum/viewto ... =4&t=13739, 2006
- http://www.mediamonkey.com/forum/viewto ... =4&t=10113, 2006 (proposes a nested structure aka hierarchy, though)
- http://www.mediamonkey.com/forum/viewto ... =4&t=15120, 2007 (asks for notes/comment field name, though)
Examples of weak support (i.e. could be helpful in solving the regarding issue, but doesn't solve it itself):
- http://www.mediamonkey.com/forum/viewto ... =4&t=25967, 2008, (doesn't solve playlist position saving)
- http://www.mediamonkey.com/forum/viewto ... =4&t=14643, 2007, 2008 (would need recognition of field type in search limitation)
These examples exclude posts in other forums. Just two examples for those (have replied, but have not started those threads
)- http://www.mediamonkey.com/forum/viewto ... =1&t=25324, 2008
- http://www.mediamonkey.com/forum/viewto ... =2&t=30204, 2008 (weak support, asks for "auto dj" feature)
Therefore I'd like to propose this for The Official Wishlist (v3.0+).
[edited 07-19]