This is a cross-post from my comment here, which I just realized is in the “Ask the Community” section.
True Named Formulas
Currently, Coda has something called named formulas, a name that only loosely aligns with what it truly is - a pre-cached/memoized result of a formula. These have been immensely helpful in speeding up some of my docs, but providing a syntax for true named formulas would satisfy a number of constraints as well as work around many of the scoping problems that we run into within advanced Coda formulas.
Rationale
Coda’s “Named Formulas” allow users to generate a result one time and pass a copy of that value around to any other formula that needs it. True named formulas would be formulas that you can use by name across a document. It is common to need to reuse logic throughout the document without explicitly reusing the value returned by that logic.
Possible Solution
It seems to me that naming a formula should work the same way so as to be fully backwards compatible, but maybe with the caveat of a new naming convention where if the formula name is followed by empty parentheses, it gets passed an argument that you can reference as thisArg within your formula (behaves similar to thisRow in the sense that you have access to it throughout the formula without running into CurrentValue collisions).
Essentially, this enforces the differentiation between what currently exists - named computed values - and the true definition of named formulas while introducing no breaking changes, no complex syntax, and satisfying other problems, like CurrentValue collisions in nested List formulas.
Example
// name: UserPerson. <- Current Named Formula
= People.Filter(CurrentValue.person = CurrentUser).First()
// name: isManagerForBusinessUnit() <- Suggested Named Formula with Argument Syntax
= UserPerson.Positions.Contains("manager", thisArg)
// In some view's Filter formula
= isManagerForBusinessUnit("HR")