Just to clarify, there ought to be no limit on Squirrel stack size, except that imposed by overall memory (and by fragmentation of the heap). Any circumstances in which a large Squirrel stack causes a problem, other than when completely out-of-memory, constitute a bug, and I'm still eager to hear from anyone who can reliably reproduce those bugs.
There is, however, a separate limit on the C stack size -- a stack whose usage only increases when the entire Squirrel interpreter recurses. There are a small number of places where this happens: in agent Squirrel only for metamethods, and in device Squirrel additionally for these APIs: closure.[a][p]call(), array.apply(), array.map(), array.reduce(), array.filter(), and array.sort(). In most or all cases, these can be avoided by open-coding the operations in pure Squirrel (with, in the case of metamethods, admittedly a slight decline in readability).
The stack-flattening techniques discussed on this thread only affect the Squirrel stack, not the C stack, and do not help with the limit on recursive interpreter invocations.
At some point we'd like to clean up agent Squirrel metamethods so that even they do not cause the interpreter to recurse, as that would remove some oddities from our agent-scheduler -- but there isn't a firm plan for doing so.