I got your next email, which suggested continuing discussion in this forum. That's fine with me, but if you want my answers in the forum you ought to ask the questions here (attached files still require email).

I don't have a lot of time to look at this, so I don't want to redo your source changes and recompile and duplicate your tests.

I haven't looked at the core code in MakeHex in a long time, but I'm pretty sure the main loop that processes the bits is at line 394, where it says
while (--val.m_bits >= 0)
If you were using msb, you can see that would introduce a bunch of extra ways that the code assumes values need no more than 32 bits (inside the reverse function and in code related to calls to reverse).
But since you're not using msb, I can't see why it would go wrong as soon as the third bit. Do you know how to use a debugger? Maybe you need to step through the code starting at line 394.
Clearly the variable Number needs to be long long for this code to work right. But with that wrong it still shouldn't fail as soon as the third bit.
Once Number is right, to process big function numbers you would need m_val to be declared long long and then depending on where the big numbers come from in your .irp file, you would need variables used in computing m_val to be long long.

BTW, you seem to be trying to generate a VERY long Pronto Hex string. MakeHex won't mind, but most programs that import Pronto Hex can't handle a very long Pronto Hex string.