WowAce

The visible symptoms are that when a retribution paladin logs in, only the first three holy power are shown.  The actual holy power being generated is all still correct, but only three points are displayed.  (So, generate 5 and see only 3; then spend 3 and see the remaining 2.)

The file modules/holypower.lua has a "global" (local to the file) declared like this:

local holyConfig = {max = 5, ...things..., powerType = Enum.PowerType.HolyPower}

and the module has an OnEnable that concludes with

holyConfig.max = UnitPowerMax("player", holyConfig.powerType)

to overwrite the hardcoded value for whatever reason.  (Presumably if there's a major class change to ret pally, this will self-adjust as a holdover until the holyConfig table gets updated.)

All loops dealing with showing the amount of holy power are all constrained to that 'max' setting, including creating the icons.  The update routine to show/hide holy power is constrained against the number of icons in turn.

After lots of experimenting, I ended up with these three lines at the end of OnEnable instead:

print("holy max initial", holyConfig.max)
    holyConfig.max = UnitPowerMax("player", holyConfig.powerType)
print("holy max after UnitPowerMax", holyConfig.max)

When the game client is first launched and the ret pally logged in, it shows

holy max initial 5

holy max after UnitPowerMax 3

If I then do a /reload during the same game session, it shows

holy max initial 5

holy max after UnitPowerMax 5

I've no idea why that UnitPowerMax call would be returning 3.  I've done the usual dance of deleting local cache folders, etc.  As such, the actual "bug" may not be SUF's and the holy power module may be an innocent bystander.  A quick grep through the rest of the AddOns folder showed lots of calls to UPM, but nobody trying to overwrite it or do anything weird.  (Well, okay, other than SUF's own "mock unitframe APIs during configuration" code, but that obviously wasn't even active.  And it returns 5 anyhow!)

Commenting out the call to overwrite 'max' was the easiest local fix to avoid the problem.

I can't say that I can reproduce this on my paladin. Is this still a thing today?

I've just updated to 4.2.2, added the 'print' lines above, deleted the local cache folders, and still see the bizarre '3' return on the very first call to UnitPowerMax during that game session.  As such, I've re-commented the 'max' overwrite in my local copy.

Adding

    print(UnitPowerMax("player", Enum.PowerType.HolyPower))

at the top of a few different SUF functions (OnEnable, OnLayoutApplied, etc) shows the same 3 value all the way through the login process, i.e., all the events firing off while entering the world.  Once in the world, doing a "/script" of that same statement prints out 5.

I'm totally prepared to believe that this is a game client bug, not SUF.  (How such a bug would occur in the game client I can't begin to guess, but long-running complex software is long-running and complex; at this point it would take Qeng Ho software archaeologists to find it.)

For whatever it's worth, this still happens in game client 9.1 / sUF 4.3.6:  same output from the print() calls if they're present, same initial-login-versus-reload behavior, all of it.  Same super-easy local fix works.  :-)

No other addon is replacing or monkeypatching UnitPowerMax as far as a quick grep shows.  I'll look more closely if I get time and energy!

Hate to say it:  same behavior in the 10.2.7 TWW prepatch, using sUF 4.4.9.

And in the 11.0.2 patch, using sUF 4.4.11 with the new internal RegisterModule API.  Broken UnitPowerMax at first login, correct on /reload and subsequent calls.