The issue is that pak is an exceptional object since all inlets produce result. If one action triggers all inlets of pak, which again triggers the ui object from which the original message originates, basically you are programming a cascade of events. That this does not create a stack overflow is mere chance. As Chris said:
> I'm more interested in why this doesn't cause a stack overflow.
Exactly the same behavior can be created with the bondo object, which is as exceptional as pak. You have programmed something which is not allowed, which is to retrigger the object before it has finished producing result on all its outputs. I remember to have run in similar situations with grab and zl. It is not a bug, but a programming mistake.
But to restate Andrew's question: why are you patching it like this? For sure there are solutions to what you try to achieve.
While there are clearly things that pak does differently than the equivalent pack / trigger combo, I would like to emphasize something Andrew said: " You're advised to stay away from trying to patch Max recursively…"
The sort of recursion that you have in your patch is bad practice for programming in Max. The result is usually a stack overflow, but sometimes a crash. Recursion will continue to bite you in places where I assume you would rather not be bitten.