Not sure I'm understanding this point.
It does seem like it will be necessary to drop eaters onto the GPSE glider-stream lanes simultaneously. So that might need a constellation with ten or twenty still lifes to accomplish that in a synchronized way -- not sure if there's a sneaky shortcut where one or more eaters could be placed beyond the collision point, such that they only start absorbing gliders after some key lane is blocked off (or after the key GPSE is absorbed and the glider stream stops).
But it seems to me that we're only allowed to drop faraway GPSEs at certain locations -- always the same phase of GPSE, and only locations where the beehive positioning works in exactly the same way to absorb those GPSEs. There's still an unbounded number of locations like that along those diagonals, so we can still encode whatever huge integers we want in those GPSE locations. (?)
That's not counting what you mentioned about "where NW distance would be restricted to be [greater than] SW distance (+/- a fixed distance) -- I haven't looked to see if there's a way around that limitation yet. But anyway, if the "data" has to be a bigger integer than the "program", or vice versa, it doesn't seem like that's a theoretical problem for calcyman's nightmarish theoretical idea.
We can add NOPs to the RCT bit stream to make the pattern big enough to allow for encoding as large of an integer as we might want -- right? And NOPs could be added to the "program" so that it's guaranteed to be bigger than the "data", or for that matter the "data" value could be encoded so that it's guaranteed to be bigger than the "program". So (I think) there's no reason why the size of the "program" or "data" integers would be a problem.
