MicrosoftI believe you are correct in your identification of nested arrays as rich data types but I do not think there are any plans to support the dot notation for attribute values (I did experiment with .name and .value but merely established that is not a supported exploitation route).
I notice your test example start as a formula containing a valid array constant. Most workbooks do not contain formulas, never mind array constants! Some of the mixed messaging you have encountered results from an effort to provide value for all levels of usage. A basic user (far the most numerous category) might input a comma separated list 5,6,7 into a cell, as a compact way of storing 3 values. Now the ▤ command (or Ctrl/J) will convert that to a nested list which is at least a first step towards being able to sum it or flatten it for inspection. I do find it slightly confusing that the list is vertical or that 5,6;7,8 is not supported as a 2D array but, frankly, it is better that you and I are slightly confused than having basic users face something they find incomprehensible.
I like your analysis of the "container" and "implicit-expansion" views. I think both are valid but, in many instances, one view is meaningful and the other not. For functions such as MAP the assumption must be that the nesting was introduced for a purpose so MAP will respect the container structure and operate upon each contained entity in turn. On the other hand SUM expects type 1 data and the decision was made to cascade the calculation down to leaf nodes where such values might exist.
That is not always the best decision, a nested Table, for example, might contain dates, quantities and prices. Summing those would not be great. There BYROW could take one through the nested records and the LAMBDA function set up to process each record correctly. A clear statement of the rationalle would be valuable but, to date, I have found the new functionality eminently usable (even tempting me to renounce the thunks I have used hitherto).
Talking of Tables, a nice trick is to use GROUPBY to break a monolithic table into an array of nested sub-tables that can be looked up individually by their group's name.
