I7 does a linear search through tables anyway, so you don’t lose anything by doing your own loop through the table looking for your multiple fields. That’d be a pain if you had to do it in multiple places, but you could do something like (untested):
To decide what number is for (index1 - a text) and (index2 - a number):
let i be 0;
repeat running through the table of hardcoded-name:
increment i;
if col1 entry is index1 and col2 entry is index2, decide on i;
decide on 0;
[then, within some rule or phrase... test for 0 before choosing the row if you're uncertain there will be a corresponding entry[
choose row for v1 and v2 from the table of hardcoded-name;
Choosing a row by row number doesn’t incur a second linear search. There isn’t a non-I6 way to get the row number, hence the manual index tracking above.
@OtisTDog wrote a multi-column table lookup I6 hack, but it’d be a little onerous in practice 'cause any routine that used it would have to have a separate choose row 'cause the compiler balks at use of entry if the routine doesn’t have a choose row. I suppose it could be modified to return a row number and this hack of mine would let you directly access column entries by row number. But my guess is that this wouldn’t even have appreciable speed advantage, so I wouldn’t actually recommend it.
Unfortunately, if you’re doing this with multiple tables, then, unless there are a huge number of them, your life would be easiest writing multiple routines that hardcode the various names.