Another idea for your connection: If you are calling polymake from C++ code, you can use the new function simulate_shell_input where you can pass an input string of any length. You won't need to generate any script files at all.
In a pexpect interface, you do not *simulate* shell input, but you *do* shell input. So, if Sage wants polymake to evaluate cmd="large command string of 1000s of characters", then it may send cmd directly via a pseudo-terminal - but large strings can be problematic in a pseudo-terminal (so, it has to do with limitations in a pseudo-terminal, not in polymake). Therefore, in the case that cmd is large, Sage may also put cmd into tmpfile, and then send the command "please evaluate the content of tmpfile" to polymake via the pseudo-terminal.
The only thing we'd have to add to its implementation is the possibility to pass arguments alongside the string, much like as in call_function(). They will land in a special array @ARGV which you can use in your expression string instead of SAGE27 and such: $ARGV[0] for the first argument and so on. This array is exempt from any redeclaration fuss and will be cleared automatically after the execution of every expression. Would this help you? I could provide this small extension quite quickly.
SAGE27 and so on are not just passed as arguments. They are the variables in which polymake is supposed to store data that Sage wants to be available for some time (in particular, data that it wants to use *after* evaluating the command). Of course, if Sage doesn't need the data any longer, then we want the variable be freed and re-used for new data.
So, I don't see how "simulate_shell_input" could improve the situation for the pexpect interface.
But parallel to the development of a pexpect interface, Vincent Delecroix is creating python bindings (PyPolymake) - I guess such a function would be of use there.
Best regards,
Simon