Maybe I'm crazy, but I do think I've found some unintended behaviour in MP3Tag here. I'll try to present what I'm seeing in such a way that anyone with the current shipping version can verify for themselves.
Here are my mapping, I believe same as what ships out of the box with a fresh install:
Tag Source Target
VorbisComment DATE YEAR
VorbisComment ORGANIZATION PUBLISHER
VorbisComment TRACKNUMBER TRACK
First, make sure you've got a datafield other than TRACKNUMBER to sort on, either a temporary custom field or as in my case your filenames may already start with a zero-padded track #.
We want to start with a clean slate: delete your TRACKNUMBER tag and confirm with whatever tool you use to check FLAC file tags
--> I use Ex Falso, but exiftool works well as well
that there aren't any leftover fields (e.g. TRACK, TRACKNO etc.)
Now in MP3Tag, get the album sorted in the right order, select the tracks and use the Auto-numbering Wizard to write a new TRACKNUMBER tag to each file - I happen to use padding, but don't think that's relevant. Note this pass don't select the "Save total count" option.
Note that MP3Tag will only show you the TRACKNUMBER field via the internal %track% value, since the above mapping makes it impossible to use %tracknumber% anymore. That value will return only the track number portion of the data, and if you're only using MP3Tag to view your FLAC tags, you'd never know any better.
However using a tool that actually shows the accurate tag name and values will reveal that your TRACKNUMBER tags actually contain the full track#/totaltracks string as is part of the ID3 spec for TRCK.
So I'm guessing the official MP3Tag answer to my OP question here wrt track numbering is "sure, go ahead, it won't cause any issues with the mainstream players out there."
And I assume this behaviour is as intended, and I have no problem with it, but feel it should be documented.
And am taking the opportunity to put in am official enhancement request that MP3Tag give the user the option to view the raw format-native tag data in their files rather than masking it behind the internal mappings (in this case of the actual data, not simply the fieldnames).
Now to what I have to believe is unintended behaviour:
Repeat the steps above, but this time do select "Save total count". Your raw-value viewer will reveal that the TRACKNUMBER field now contains "X/YY/YY", e.g. 1/17/17 and of course this does cause problems with I assume just about every player out there.
If there is a better location for me to file a proper bug report, or my above wishlist item, please let me know.