I assume widespread use of 2.5 is not that far in the future, say a few months at most. Given that, I currently think it's beyond the scope of the VB fork to radically change DNA execution fundementals, in particular to make any fundemental changes to the two-step process of 1) execute all the DNA to load up the mem array and then and only then 2) do what the mem array says to do. Said another way, one could imagine creating new in-cycle execution artifacts which would allow for separate, per gene execution, shooting multiple types of shots in different genes per cycle, changing the value of tienum to address different ties in-cycle, etc. I don't want to make changes of this magnitude in 2.4 if 2.5 is only months away. If 2.5 slips out, then we can re-visit changes of this magnitude, but that is my assumption for now.
So, that means any operational parallelism in 2.4 will require specific sysvars. IMHO, this leaves several options for 2.4 regarding addressing multiple ties in a single cycle:
1) Do nothing. This is why I asked eariler whether anyone actually used .tielen1-4, etc. in 2.37.6 If no-one does, no big deal. I won't make them work and I won't have to deal with the issues you (PY) point out so well.
2) Make them work but don't deal with the issues with ties getting deleted, more than 4 ties, etc. This might be sufficient for designers moving from 2.36.7, but strikes me as hackish and incomplete.
3) Make them work, but limit them to 4 ties (you can have more, but you can't address them in parallel) but deal with tie deletions. I could do this by making some implicit rules that the first tie to fill a slot will be bound to the tie sysvars for that slot unitl it is deleted and maintaining a per-bot mapping from tie to tie sysvar and changing that as ties get added and deleted. If there are more than 4 ties and one gets deleted, maybe the least recent tie not mapped to a sysvar takes the slot or not... Or perhaps I could add a .settievar that would allow the bot to explicitly map ties (via tienum) to parallel tie sysvars for parallel addressing....
4) Add more sysvars for more than 4 ties (I think you can have 10 ties in 2.4). This would be 16 additional sysvars (.tielen5-10, .tieang5-10) plus still would need to be explicit about deleting/addition behaviour as in 3) above.
In my mind, 3) is the default plan but I'll noddle it for a a few days before I start. I am of course, very open to better suggestions...