It may be that you MUST have the separated tables but I wanted to describe how it could be if they were combined - putting together what @1minManager proposed as the solution, your comment above and what I mentioned about combining tables
With combined tables consider an expression like this:
SELECT(CombinedTable[ReturnColumn], [Column] = [_THISROW].[DesiredTableRow]
In the CombinedTable, the [Column] value would correspond to rows from the separated tables - i.e. "foo’ for all the rows from “Table1” - the first IFS above, “bar” for all the rows from “Table2” - the second IFS.
The [DesiredTableRow] is the dynamic value synonymous with the dynamic table name idea.
Now you can dynamically specify the value of [Column] to get the rows for what was a separated table before - basically the [Column] value is filtering by what was the separated table.
And of course you can add additional filtering logic when needed using AND(), OR(), NOT() ect.
The only reason I am hitting this again is that I know from experience that if you have like tables that are separated you will be finding yourself implementing complex IF() and IFS() expressions, like the above, all over the app as time goes on. If the tables can be combined, it will be MUCH MORE EFFICIENT to do it now and fix up the app views, etc, than dealing with the expensive development and maintenance later.
Just a free piece of professional advice.