Tag %track% incorrectly includes %_total%

When converting tags to file names, MP3tag includes the total number of tracks into the track number. This was not the case in previous releases, although I've read that the problem has also occurred in releases as far back as 2016.

In other words: %track% now is 01/27, 02/27, 03/27 etc which will be converted, in a filename, to 0127, 0227, 0327 etc.

However, I would prefer %track% to be just the number of the track: 01, 02, 03 etc.
The total number of tracks can be used through %_total% anyway.

Thanks for reading this and thanks in advance for any follow-up.

(BTW: I know that there is a workaround: use $num(%track%,2) instead of %track%. But it would be more logical and consistent if it would be as requested above.)

The function was there as you describe since way back when. So I doubt that your allegation is correct.

In which tag version do you find that?
Or: have a look at the supported tag fields in the help:
where you don't find a field called _TOTAL.
So it looks a lot like a user-defined field to me.

This would then not be according to the MP3 standard, which states
The 'Track number/Position in set' frame is a numeric string containing the order number of the audio-file on its original recording. This may be extended with a "/" character and a numeric string containing the total numer of tracks/elements on the original recording. E.g. "4/9". "
(see https://id3.org/id3v2.3.0, search for TRCK)
I don't see a bug. On the contrary: I see most of the changes that you demand as a step towards a non-compliant non-standard handling of the field TRACK.

I am using MP3Tag since 2009 and Mp3Tag always included all information of the tagfield TRACK.
For naming files you always had to use $num(%track%,2) if the total number of tracks was included in the track-field.