Writer was added because we don't always know whether it should be composer, lyricist or both (or whether it's really just the author of a book), so I think it should available separately.

To be fair, Picard still applies release relationships to all the tracks (even though they technically could be fuzzy ones) so there might be some trade-off here between doing what's reasonable most of the time vs. providing some extra vaguely secret functionality most people won't know about

Yes... I can live with both solutions, but as voiceinsideyou noted, given that Picard has a history of converting fuzzy ARs into non-fuzzy ones, it might be the easiest to convert it to lyricist/composer.
File tags will never be able to exactly store all information in the database, so some pragmatism is good.

But, as the ticket title indicates, I'm also happy with a new metadata variable!

There's nothing stopping people from copying writer to composer and lyricist if they want that, is there? But if it automatically maps it to composer and lyricist, how can you undo it?
I guess I'm just wary of letting Picard make too many of its own decisions because one of the main reasons of tagging using Picard for me is that I can (more or less, it's not perfect yet) customise it to tag exactly how I want.

Yes, there is . Tried it with one Beatles song, it got auto-corrected to "written by" because no detailed information is available (or is contradictory). So I guess an additional meta-variable is the best compromise!

But as voiceinsideyou noted, Picard does currently hand down release ARs to recordings, so this is already done automagically without user intervention...

You're right nikki; and I think it's probably best that this is added as a new variable (actually, it'd be good to do an audit of all the ARs to make them available as vars if they are currently not) - however it's worth noting that a lot of people won't touch scripts. Perhaps there's a case for some more flexible plugins to address relationships.

I also think "Automatically replicate release/RG ARs across tracks" should be an option. Personally I like the current default behaviour for tagging, but it's a bit odd as a default given we actively encourage editors to propagate ARs at the lowest level possible.

The writer -> lyricist one is more contentious. Instrumental tracks can never have a lyricist, and for much mainstream music lyricists and "composers" are not explicitly credited. If you look at even the way that WMP and other media players source and use the composer tag - they are usually getting data from a data source that is basically "legal songwriting credits" which can encapsulate both composers and lyricists anyway. I guess I would argue that most apps are in fact using the "Composer" tag as a "writer" tag anyway - in part because there are no good data sources for separating these two roles (although obviously we want MB to become that source!). Prior to MB having "written by" I extensively mass-ARed albums using composer to represent liner notes that really just represented legal songwriting input. (impossible to know objectively whether 50 Cent just writes rhymes or actually sits alongside the producer and has direct musical input in addition to the producer's... but I DO know they both have equal songwriting credits; for example.)

Yeah, I realise it's not ideal having to do it with scripts right now. I hope we'll eventually get some advanced options where people can customise which variables are written to which tags (to some extent possible right now using set/unset) and which tags are cleared, overwritten or left alone (so people can stop requesting that their favourite tag doesn't get removed when we tell Picard to clear all tags first).

Submitted for pull/review at https://github.com/musicbrainz/picard/pull/17

Looks good!

One of the problems with this is inability in scripting to deal with lists. Arguably, this means the work should be done in plugins.
The current code would allow you to do

$if(%writer%,$set(composer,$if(%composer%,%composer%; %writer%,%writer%))))

This would flatten multiple writers and composers into a single entry; annoying if you're an ID3v2.4 or other-type-of-tag user.

Alternatively, perhaps there's a way we can give some simple functions to allow the text values that scripting creates to be coerced back into lists for display and tagging.

https://github.com/voiceinsideyou/picard/commit/47fa54da875c186d7daf9c21d00b08806dcb09b5 is an idea for allowing script like

$if(%writer%,$setlist(composer,$if(%composer%,%composer%; %writer%,%writer%))))

which would split by semi-colon (Picard's default joiner tag) prior to altering state.

Other thoughts

1) removing duplicates?
2) sorting/merging of text lists?
3) Maybe should be $setmulti instead; focusing on the tagging aspects, rather than the internal data structure.

Any thoughts on this? Other uses for such a thing?

Argh, sorry for not realizing it earlier, the tag should probably be named %_writer%, because it is not written by default. Can you change that before the next release?

No, the %writer% field should be saved to tags.

Hmm, as you said, it is currently only written to freeform formats like vorbis. I think it should be either written to all major formats, or none of them...

So either something like TXXX:WRITER would be good, or just renaming the tag to %_writer% I guess.