HeightOffset missing, normal is undefined, also I suppose the experience bar is normal too

"Height of a normal sized bar" doesn't tell us which of the three bars are refered to, so why not just refer to "size of the health and capture bar" and that "size of experiencebar" is scaled proportionally by a factor of 2/3, then everyone knows what's happening.

Would be good to have HeightOffset defined (at least we must know it's definition already in order to decide the correctness of the patch, so the only effort now is phrasing it).

But if you insist, I can change that...

If I would insist I would have had clicked on requested changes.

I don't care about these 3 lines, but the recognition of the possible disadvantages of default arguments that do not occur before the pattern was already extensively used.

At least in rmgen there were a load of problems because defaults that are expected by the users were used, then it accumulated into an unreadable mess. These are only two cases #4989, rP21728, another one was the hardcoding of the tileclasses like clWood in the placement helper functions (which broke maps that wanted to not use the exact same variable names or didn't use some tileclasses).

Maybe there is a reason that there are almost no default argumens in the simulation, but maybe it's just coincidence...

Other than that there is still the point that if the template is supposed to determine the position and size of the health status bar, it seems contradictory that the simulation code and not the template would determine the position and size of the other status bar.

(I personally don't insist or really care about that either though)

StatusBars.prototype.Schema doesn't actually define what it should be.

The point is that the 2/3 number of the bars is considerably not an internal logic constant with inherent universal truth to it, but as much as a userchosen number like the other user chosen magic numbers that depend on the specific entity and are expressed in the template.

The benefit of hardcoding the 2/3 is that one doesn't have to specify it in templates, which can make it less error prone, easier to manage; but perhaps there are some entities for which 2/3 isn't the best number? For example some entities have smaller status bars, the numbers were specified for health bars. Someone could have chosen a number that is so small that it's just right for health bars, but 2/3 * healthbar size would be too small for the template authors taste.

2/3 just smells like a magic number, and one that even obfuscates other hardcodings like the offset.

As mentioned there might be no relevant vanilla 0ad entities that are use cases, since mostly animals have different status bars from what I recall, and animals don't have experience bars. Perhaps we one can construct an example use case of an entity where the hardcoded layout fails.

The question is, why is the user granted the freedom to edit BarWidth, BarHeight and HeightOffset, but not the freedom to change the 2/3 and experience bar offset.
Just because the capture point status bar used the same principle of a fixed layout doesn't mean that it was inherently the best choice, or even a conscious choice, other than taking the path of quickest implementation (unless we have some trac or irc logs remaining of the reasoning).

StatusBars.prototype.Schema should receive the definition of that, so that we actually start documenting what the properties are supposed to change.

So if you as the author and commiter decides for the fixed layout, BarWidth, BarHeight would relate to the size of the Health and Capture bar, and should state that the experience bar is scaled down proportionally, and HeightOffset being the vertical distance from the entities position (at the foot of the unit?)

Just as a mathmatical consequence of the patch, adding a new experience bar of the size 2/3*BarWidth below the HeightOffset might make it possible for one entity to have it's head overlap with the newly added status bar. So one should check that this doesn't happen with the vanilla entities, but then again I think none of the entities were affected because animals don't have experience bars, and most of the bars of units are probably far enough away (one could ensure).

Anyway, your choice as the author and committer to disregard those mere 3 bytes in the file that would take some time to get rid of, which can still be done by the hypothetical future 2/3 editor.

Then it might be wrong if there is negative HeightOffset somewhere, which I guess we don't have.

That there is a mathmatical possibility that an entity template exists for which 2/3 is not the best, or even a wrong magic number. Vice versa a proof that none such number can exist for all HeightOffset values ("decimal") would be part of a verification of this patch.
I suppose all HeightOffset values in the current vanilla 0ad templates are greater than 0, so there'd be that verification for vanilla. But 2/3 could still be wrong for some future addition or mod, for example if the bars are set below the unit instead of above (negative HeightOffset). (Templates have the purpose to hold values that are specific to entities while code has the purpose to work indiscriminately to specific values.)