Also, while working on that previous post I discovered the reason why this CurrentValue issue is not so easy to address, from design point of view.
First, I think everyone in Coda wants to avoid going with CurrentValue1, CurrentValue2 etc. From a software engineer point of view this doesn’t look elegant at all. Not only the suffixes 1 2 etc bear no meaning other than telling variables apart, I can see how this would break many formulas relying on CurrentValue being the one from current context.
However, with the way how Coda currently works with variables, we cannot have multiple CurrentValue (with different color coding) either.
The first reason is logical: what if the outer loop and the inner loop use values from the same table, e.g. Tasks.FormulaMap(Tasks.Filter(...))? The colors and types of an inner and an outer CurrentValue would be the same then.
The second reason, however, is technical. Turns out, variables ($$[variable:...] items) are actually distinguished by their name, not an ID (and it makes sense):
Even if you supply some random arguments to the $$[] reference formula in place of actual grid ID and object ID, Coda will ignore those and replace them with the grid ID of the collection that CurrentValue is iterating over (I believe for coloring purposes only). And if you keep the IDs but rename the variable, it will resolve to blanks:
Doing the same thing with a row reference would do the opposite: still point to the specified object ID and row/column ID, and replace the name to reflect the actual name instead.
So this is why it’s not possible to have two CurrentValue variables — because unlike row/column references, variables are referenced not by any internal IDs but by names.
(Also you could’ve just told us so 
I know you want to communicate the reasons in a simple way for the majority of non-technical users to understand. But sharing the technical reasons would not only be very appreciated among us power users, but we’d be able to pitch in with better educated suggestions.)
Given this knowledge, I have another approach in mind. Keep CurrentValue behavior as is, but introduce a new variable CurrentValues that would be a list of all CurrentValue down the function stack. I.e. CurrentValues.First() would always be the outermost one, CurrentValues.Last() would be the innermost one (always the same as CurrentValue), CurrentValues.Nth() would give access to intermediary ones if needed etc. Technically it’d be as simple as push()ing and pop()ing a value in/out of the array whenever you’re entering/exiting the nested context (i.e. in the same pieces of logic where CurrentValue is changed). I imagine this would be the simplest addition (no extra syntax required), an elegant one, and pretty much solve the pain point. @shishir