MicrosoftEd Hansberry PeterBartholomew1 I'm still thinking about this, tho.
For my applications, looking up a value from a source Structured Table for use in a destination Structured table, will want to return a single value (or single sum of values), into the field in a row in the Destination Table containing the XLOOKUP expression; replicating this operation in each row of the destination Table.
It's helpful if the return column specification is programmable by data in a field in each destination table row initiating the lookup, so that the return column name doesn't have to be hard-coded into the expression, ie so I can get a 2D lookup. I'm using INDEX/MATCH/MATCH now to get exactly those 2D lookups among Structured Tables, and that provides linking that's nicely dependent on data, and independent of its location. Looking at the announcement of XLOOKUP, I'm stressing on how to specify the return_column in XLOOKUP, finding it from the Destination Table[#Headers] range.
I'm basically checking whether Microsoft targeted XLOOKUP toward use of INDEX/MATCH/MATCH with Structured Tables and if so what they think the syntax looks like. I don't yet have access to XLOOKUP, so can't check it myself, but am interested in what others may find. My description above is what I think it takes to get an equivalent to INDEX/MATCH/MATCH with Structured Tables.
(By the way, I credit Bill Jelen with the 2D XLOOKUP syntax in my example; he stated it using cell addresses, and I'm trying to understand if it targets okay to Structured Tables using Structured References and #Headers, so I can get location independence when linking, which is nicely powerful.)
