This will be a huge speed boost for most solutions using unstored calculations
Nowadays, if in Table_A you have such a calc fields, and you display them on a layout (or export them)
Price_with_VAT = price * (1+foreignTable::VAT%)
Sales_Price = Price_with_VAT*(1-discount%)
Price_with_VAT will be evaluated 3 times instead of 1, and Sales_Price 2 times instead of 1 :
That's 3 un-necessary calculations, so this lead to 6 calc instead of 3, sot at least 2 times slower (and due to side effects maybe even more).
It's actually worst than that because it needs to evaluate foreignTable::VAT 3 times instated of 1 and price 3 times instead of 1
And there's no workaround for it.
So when evaluating a record's fields, filemaker should cache in memory the result of each calc fields, just for that record. There's no point re-evaluating them, their result won't change (and if they were to change due to a foreign field changing that would cause terribly wrong results).
I know there're concerns about the order in which those needs to be evaluated, but remember that filemaker doesn't needs to cache all records fields, only those that are currently used (displayed, or exported, involve in ExecuteSQL), since Filemaker knows perfectly knows the structure, it's easy for it to evaluate the dependence tree order either at run time (and only once for the first record, for ExecuteSQL) or caching that dependencie tree when committing the layout or the export.
This will be a huge speed up for lots of list views, that will re-allow the usage of unstorred calc in many solution in which they are banned due to speed issue (at the cost of heavy workarounds), which is a shame because unstirred cals are a huge benefit of filemaker for code simplicity.