I’m almost certain this has nothing to do with the way you enforce lower bounds on stats.
If we take what the person said in the thread at face value, (and from my testing it does seem to be the case) then this is what happens.
At some point in time, for an unknown reason the patch that the gringe patch is now based upon has added a piece of code to the way stats get saved.
In the normal JP variant of FE6 and also the other patch that you included, when the game saves it just saves the current stat into the SRAM, that then gets loaded so there is no problem, even with negative growths.
Now that injected piece of code changes it so that instead of saving the current stat, you save the current stat - the personal base in that stat.
Lets take Bors as an example, since he is the first one where I saw it in this case.
The stat that is most likely to underflow is his speed, now the question is why.
At base level Bors has 3 Speed, The Knight class has a class base in speed of 0, so we know all 3 speed he has are from his personal base stat.
In JP FE6 & the non-gringe english patch, when he levels up in speed, his new base speed of 4 gets saved to the sram.
In the gringe patch, it will instead save current Speed stat - personal base stat.
The saved stat is equal to his class base speed (0) + all speed points he has gotten from level ups (1).
When it then loads the game it takes his personal base stat (3) + the stat saved to the SRAM (1) adds those together and we get 4, which is correct.
Now lets use this example in the context of negative growths.
Bors gets his first speed level up and goes from 3 speed to 2 speed.
When we now save the game, it will save the current stat (2) - personal base stat (3). This results in it saving -1 to the sram.
When it saves -1 according to the person in the thread this happens during loading:
But if you haggle twice, now the bug rears its ugly head,. 11 - 12 = -1, -1 is represented in binary form as “11111111”. When the original game takes over and smush everything together in SRAM, it only uses 5 bits of each stats, so 11111111 becomes 11111, or 31 in decimal, instead of -1. Now when you reload, the injected code doesn’t check for this kind of overflow, and just add the character’s base stats as always. So 31 + 12 becomes 43.
Now, because of the way the glitch occurs (subtracting the personal base stat from the current stat) the glitch is easies to see when a character has a much higher personal base stat than the class base with the exception of luck which for some reason allways seems to be unaffected.
For characters with good class bases such as Marcus this will still happen, but it takes a lot more level ups for each stat so that personal base stat > current stat