A bigger and better solution would be to fix the automation/envelope dialog to display it in a table format with a destination for each.
This would be like a "mod matrix" and the destinations could then be switched at will.
The issue is really due to the way reaper is implemented internally... which I don't have access to. We can see though that project files store envelope lanes by parameter index alone:
Code:
<PARMENV 5 0 1 0.5
ACT 1 -1
VIS 0 1 1
LANEHEIGHT 0 0
ARM 1
DEFSHAPE 0 -1 -1
PT 0 0 0
PT 0 0.75 0 0 1
PT 16.27118644 0.225 0 0 1
PT 56.94915254 0.815 0 0 1
PT 81.3559322 0.245 0 0 1
>
So there is no reason to think they aren't stored the same way internally. If they were stored by a unique identifier ("envelope lane index") instead it would require no changes to the internal structures. Only the creation/deletion/mapping would need to change.
A data member could be added for "parameter name", "parameter index". This would store the last mapped parameter and would enable a warning flag to be activated (red box? red x?) to notify the user of a lane that isn't mapped correctly.
Another member "lane name" could be added to allow the user to rename a lane in any way they like. This could default to blank (not set) where reaper could then display the parameter name from the stored index (not the stored last known name.)
The display in the "mod matrix" envelopes dialog would then look like:
Code:
#index: lane name - target name (#index)
You could change the lane name, erase it to set it from the target parameter, right click to select "copy", "paste" and "delete" and see a "flag" that could light up to show any error (last parameter name != parameter[index].name).
Most behaviors would remain identical and most code should remain unchanged.