Both of you raise valid points, should have kept my mouth shut for a few more days but now I have a prototype to finish over the weekend. 
So, stay tuned, it’s possible — probable, even — memoization is overkill for exactly what I had in mind here but I’ve had reasonable, measurable success with it in the pre-cold-polling-recordIds era of Airtable.
And the “what I’ve had in mind” part was largely inspired by posts like BlockChaining and, coincidentally some side-loading exchanges between precisely you two (first one I found). All of which made me start consciously viewing Airtable as the already-turing-complete-platform that it is. One whose coplexity limitations are as arbitrary as they are arbitrarily circumventable. Maybe even without things getting too hackey outside of the comfort of its box.
Bottom line, after a year and about half a dozen prototypes. I think I’m close to a fairly end-to-end system for extending Airtable scripting logic. Or rather, easily writing logic that’s way more complex than what the Scripting environment normally makes convenient, without actually leaving the scripting block or using any “outside” help other than maaybe an extra table in a given base, whose records are treated as modules of sorts.
In limited testing so far, a code base north of 40k characters (so, even someway before surpassing the vanilla app limit) would already benefit from memoization substantially. Especially memoization of the staged variety, though I’m not that thrilled with this part of the code base yet, it remains a way bigger mess than it should be. Regardless, the basic approach I’ve had some succcess with so far was charting out my mini dependencies between code modules split across Airtable records on runtime, memoizing what’s needed, and proceeding to run from there.
Reading the objects (sometimes even more elaborate code involving a few classes and the like) used for instantiating individual app prototypes has so far been straightforward, as well. Regardless of whether the JSON or full-fledged code is partially stored in a description of one or more tables, fields, or a combination thereof.
One cool pattern I want to say I planned but have mostly just stumbled into has to do with prototypes of somewhat user-facing apps; the kind expecting at least a minimal degree of UI interaction during runtime. So far, those have been trivial to manage by virtue of giving me breathing room to bundle blocking memoization calls into Promise.all and Promise.race methods seemingly tied to the app awaiting user input. Modern garbage collection’s been taking care of the rest so far. How well, I can’t tell until I try scaling this to a level whereon it might actually matter one iota.
Not sure if the end result will be anywhere near as capable as even the most basic use case for something like on2Air, but the intent is to open-source it all anway as a curiosity. Because at the end of the day, this was always a just “yes, but can it run Doom I might be dead before I learn enough React to just churn out custom apps with grown-up code-splitting in production” project. Mostly a testament to how much I enjoy messing with the Scripting app + Airtable combo even with all its limitations.
So, again, all valid points, will do my best to follow-up with some numbers after I write a few more test cases quantifying large-scale benefits of memoization, or lack thereof, for this and similar use cases. Oh, and maybe an extra test case focusing on how much absolutely none of this doesn’t even matters any longer now that we have granular control over individual records being polled (not that I’m complaining).
Tl;dr: I won’t be applying for any cybersecurity roles in the near future and I take my procrastinating very seriously.
