Good discussion. Tossing this in for anyone else having this question.
List(2,3,4).FormulaMap(
CurrentValue * 2
)
4,6,8 
This is the new list comprised of each value from the original list transformed by the formula invoked in FormulaMap().
FormulaMap() is a forEach() loop that returns values. For each value in a source list, FormulaMap() maps a formula to each one of those values, meaning that it runs that formula on each value in the list. The results are returned in a new list containing the transformed values.
Defining the list is the key, and often the hardest part.
Filter() is designed to define lists that meet specific criteria, so I tend to use it frequently for this purpose.
One of the most powerful uses of FormulaMap() is to run it on lists of row objects. After you define and build your list of rows, then you can run a formula on each one of those rows, incorporating data from any of their columns. See the simple example below.
Some Additional Details
I consider it a best practice from a manageability standpoint to actually build the list of rows some place, and then reference that list using FormulaMap(), rather than trying to both build the list and run FormulaMap() in the same formula.
Unfortunately, this conflicts with the way Coda uses memory for row references. This shouldn’t appreciably affect most use cases. It only comes into play when you generate lots of row references via lists, which some of my key workflows require. I would be most interested to understand the rationale for row refs consuming so much memory (I’m guessing it facilitates the hover access). This row ref memory issue is damaging to the core functionality of filtering relational tables – I’d like to see it optimized at some point.