It might not be so easy as what you suggest. What you say might all be fine on source file formats that use ID3v2 tags. But MC must also compatibly handle those formats that use other tagging schemes e.g. m4a, flac tags etc.
I know.
You only need the correct logical data fields and map it to the physical fields depending what is supported & possible - and options might have to be prepared in the preferences.
A mapping table from MC's logical data field into the physical columns in the twiki (or does it exist?) will help the user what is possible with the file format the user prefers.
Here is an example page from MP3tag.de:
http://help.mp3tag.de/main_tags.html#TCATOf course - new columns arrive from time to time. Also ID3v2 does not support all - but TXXX helps to create missing columns. When e.g. ID3v2.5 will arrive with additional columns then everyone who want to swap from v2.4 to v2.5 has to copy his TXXX to the new T???. And maybe store this one value into both tags for some time.
If ID3v2 in WAV wouldn't be possible I would have a problem with WAV because the LIST INFO chunk doesn't support so much columns I want and I would have to find another solution.
They simply don't care about a distinction between the album's original release date and any other dates. They want a Date.
You are forcing the people to use ONE date column?
What would you say if I would say - "here you have ONE text field - store whatever you want". I am sure you wouldn't be happy to have artist, album name, track title, etc in one text field. ;-)
At first it is a great & big difference if you have an album bought in the 80's on CD or a "remastered" later. Compilations arrive usual later and have a newer release date as the track itself.
The logic of the dates is different:
Recording Time = track based
Release Time = release based (single, album, compilation, etc.)
I know a lot of people from discogs.com over the years who are updating any bad data and correct them and store both date columns in their files as I do:
Track "A Taste Of Honey_Boogie Oogie Oogie_(Original Mix)_[987752].wav" ...
http://www.discogs.com/release/987752Recording Time = track based => TDRC = 1978
Release Time = release based (single, album, compilation, etc.) = 2007
Original Release Time = release based (single, album, compilation, etc.) = also 2007 in this case because this compilation has not been release before. It's not a reissue.
Finally:
If the user want ONE date only then he only needs to use ONE date and not 2 or 3 dates.I (and others) want 2 or 3 dates as supported by the standard ID3v2.3/4 and when the software (MC) is not able to handle it - then it is the wrong software for me because the minimum requirements for me are not there.
But I am sure - if you have 2 or 3 dates as above - and users are insterested in to have this information and correct data they would fill it in. Currently the MC users can't (except creating own TXXX columns - not always portable to other software).
E.g. I have not bought the car SKODA because their brand new cars do not have an USB to connect - although it is a standard today! I have bought a HYUNDAI i30 instead. The USB was one of my minimum requirements for a car. Others maybe only want a cassette. ;-)
You are in a special segment of the user population, that is, one who does care about these matters.
I am sure there are more people who want 2 or 3 dates instead of one - as people who needs Dynamic Range values stored - and there are 2 (!) columns for it ... only one example.
I'm very confident that the Date field will not go away or be renamed
The physical value shouldn't go away. If MC wants to name it "Date" or changes the name to it's meaning (this always happens with various things on newer software, etc) - however - MC supports a display name. Ok for me and others. As long as I know how it works and where it is visible in other programs - ok.
It is a legacy field, and a change here will break many 3rd party apps, backup libraries, etc.
I don't think it will break many 3rd party apps. Currently MC breaks the standard (ID3) and a lot of big software which uses the standard correctly. Backup libraries? Don't understand this why it should break my backup? I backup my current files ...
The Date field has the capability of encoding both date and time data.
That's good! I don't want anything else. I will store my 1500 japanese CDs with the full release date from discogs.com (printed on the release).
btw. you might not have noticed it above: ID3v2.4 "TDRC" stores date and time in one column. In ID3v2.3 the column TDRC was splitted into 3 parts: TYER (year), TDAT (day+month), TIME (time).