Instead of using IF ELSE, another way to achieve this is by manual mapping i.e., creating a mapping module and map native, custom versions(versions list) then use LOOKUP function to get the data from native to custom versions.
Disadvantage: we need to manually map newly created version each and every time.
For the use case which prompted this query they add versions every quarter.
Rather than cycle through existing versions they would rather create a new one and delete any unused versions.
Therefore, using a LISS or nested IF THEN ELSE requires them to update the formulas/mappings each time. As this transformation occurs multiple times it can be a significantly time consuming and error prone process.
Have been working through a similar scenario (and have also run into the same issues).
Sounds like you have an approach that works for you, but have attached my 2c.
Haven't found a way I'd say I'm happy with, but given the sizing implications of having to stage modules along the way, I opted to use a SELECT/SUM approach to do the transfer from native version to fake version in one step.
My approach was,
having the source module by version
target module has same lists but instead of version, using fake version
using a formula in the target module of source line[SELECT:Version 1, SUM: Mapping Module.Fake Version 1] + source line[SELECT:Version 2, SUM: Mapping Module.Fake Version 2].. etc
With the data now applied to the appropriate fake version,
I'm free to either use it as is, or use a LOOKUP to send it elsewhere
I can also setup other reports with toggles which allows users to choose which fake version is used in reports/calculations, and
I can also subset the fake version list further if only a few of the versions were required.
My scenario however didn't involve frequent updating of versions and even if we did, we only had ~6 lines to update which would take ~5m. Only other implication is that changes are WSA-only and need to be deployed.