And yet another edit that caused a little controversy:
The voting is a bit one-sided at the moment but it seems that working practice has outpaced guidelines again. The FeaturingArtistStyle has always been the bone of contention (see SG5DisasterRelief for example) – now the question is if AdvancedRelationships as a mean of crediting of what an artist has actually done on a release (in NextGenerationSchema-talk: “what it is”) are shifting the “feat.” in track titles to a role where it only credits “what it says”, that is when the artist intended to credit guest appearances prominently on the cover.
The con is that the presence or non-presence of “feat.” on covers barely expresses artist intent because it is done by cover designers and mostly the artist doesn’t have a say in the design.
MetaBrainz Blog 
style guidelines aside… how do you prove that track titles SHOULD include (feat.)? and when?
okay, designers don’t follow the MB style guideline.. but who are we as MB editors to rename the artists titles to include (feat. X) when it’s not listed anywhere?
I am for keeping track titles as track titles and use advance relationships for artist to track relationships.
we don’t put any other pre-existing field into some other field.. example release types in release titles (unless its part of the title [think EP]), why should we on tracks?
if you want to get rid of the (feat.) problems, get rid of (feat.) 🙂 That way you don’t have to worry if its the artist intent or the designers intent.. because the track field will only contain the track title.
My loathing for the stench of (feat.) is well documented (http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-May/000107.html and http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-October/000465.html), so I’d love to see us keep “featuring” information to the ARs.
When the last server release added the display of ARs to the album page, I considered bringing it up again, but since there was a lot of bad blood during the release, I decided to keep my nose out of it for now.
The absurdity of (feat. xxx) is especially evident w/ Classical releases as most of the release titles become ridiculously long after you’ve added the conductor, the ensemble and the performers.
I thought it was established that the dreaded FeaturingArtistStyle would be changed when the website could display track ARs *and* Picard could construct tags from ARs. IIRC it was also established that until then, “(feat. xy)” would stay in the track title.
The former has become reality thanks to Keschte’s rework of the server display code, now we still need something like the TaggerScript. AFAICT this will be part of the Qt rewrite of Picard. But I do not believe the StyleCouncil will change the guidelines before Picard supports ARs.
Please keep in mind that we are talking about a pretty substantial change in the semantics of the database.
Note that the edit mentioned above is not about removing *all* feat info, but only about removing it when the feat info is not prominently displayed on the cover, but only in the liner notes.