ID3v2.3/ID3v2.4 tag-size differences/derivation

When writing/saving a single string-value (e. g. in Title) as ID3v2.3 to a non-tagged/empty mp3-file, the required tag-size amounts to 2229 bytes, also when additional (four) fields are filled with the same value. But when several (all five) fields are filled and written at once for the first time, 2401 bytes are required instead. Which actually depends on how much fields are initially written together.

For example writing the value '0123456789ABCDE0123456789ABCDE0' sequentially one after another (multiple saves) in five fields results in 2229 bytes. Writing the same at once for all five fields, within one/the first saving action, results in 2401 bytes as total tag-size.

Is it possible to retain the minimum required tag-size automatically, perhaps as optional setting, even if it will slow down the writing process?
What's the reason for the (redundant) 'expansion' of the tag-container when all fields are written at the same/initial time?

Is there any difference in performance and necessary reading-time of mp3-tags whether it's written sequentially (lower tag-size) or altogether (larger tag-size) for other applications/devices?

(Custom columns %_tag_size% + %_tag_size_prepended% can be used for display of required bytes.)

Here is a thread on tag-padding:

Perhaps you look for padding with the search function and see the current course of the discussion.

I've read about it there: Anzeige der Tag-Größe (%_tag_size%)
According to this, mp3-files with existing tags that should be preserved need to be rewritten as a whole to remove the padding/unnecessary space.
Yet my described behaviour only relates to 'cleared' mp3-files without any tag-data included, so the tag-container will be created and written 'from scratch'. If 'padding' would be the cause, why not avoid it for the initial tag-creation process (as far as possible)?

Thus is it feasible to tell the program to create the ID3v2.3-tag with only the string-data from the first filled tag-field and add every other remaining tag-data afterwards?

Guess there won't be any solution soon, so I'm gonna use id3mtag integrated as Tool with following parameters:
-M -2 -s 432 "%_path%"