your option 1 is the one i use most.
i regard tables as a type of class (using OOP concepts here), so rows are objects, columns are attributes.
so formula columns are functions, they take other columns as arguments and return values.
by similar analogue, button columns are object methods, again, taking other columns as arguments.
if i need class methods, i create a seperate 1 row table for those. and i create similar 1 row tables for global procedures. they have columns for arguments.
your option 2 ‘use a pack’ is possible but not good
currently packs run on the coda servers, so there is an indeterminate delay in their execution. also, it uses javascript and not coda language, so the idiom is very different and complex.
option 3 ‘black magic’ is possible but not supported.
you can insert pure-text formulas into the json object of an Action column and it will be executed. it requires use of unsupported functions and depends on the inner structure of coda objects - so it could break if coda change stuff in a future release.
i use this ‘black magic’ in my BASIC and JAVASCRIPT emulators, if you want to take a look.
i am working on a document to explain this trick clearly (but client work has pre-empted that so far).
finally, i have just recently posted a technique to execute simple formulas using named variables that i want to modify to allow named arguments as well, it does not need any unsupported black magic. watch this space.
respect
max