Sorry about that. I'll just describe it as I should have originally :-)
We have a screen, as per the screenshot below:

The structures are defined as below:

MainStruct is a list of ChildStruct. ChildStruct is simply a 'param' of type text. The specifics don't really matter other than the MainStruct contains a list.
Reproduction steps:
In the Data Action Step 1 above myStruct is populated. It could be from a database, or from the output of some method. Specifics don't matter. What matters is the nested structure. Serialized output of myStruct:
{"children":[{"param":"child 1"},{"param":"child 2"},{"param":"child 3"},{"param":"child 4"},{"param":"child 5"}]}
If you access myStruct from a Client Action everything works as expected.
In the Data Action Step 2 it will not work as expected. Step 2 Data Action simply reads myStruct from Data Action Step 1 and serializes it and saves it to an output parameter. If then in a Client Action you display the output, you will see the following:
{"children":[{"param":"child 1"}]}
That is the optimization I'm talking about. Because Step 2 is a Data Action, and it's reading content from Step 1 (another Data Action) OutSystems will silently optimize and only return the first item in the list. I contacted support and this is expected behaviour, it's simply not documented.
This is totally not obvious to the developer. This is why I recommend at minimum that a warning be presented to the user at compile time.
As a final Data Action Step 3: Sometime before you call that Data Action, use a a Client Action to copy myStruct from Step 1 to a variable (e.g. copiedStruct) and then access copiedStruct from another Data Action then it will work as expected:
"children":[{"param":"child 1"},{"param":"child 2"},{"param":"child 3"},{"param":"child 4"},{"param":"child 5"}]}
To summarize, if you access the output of a Data Action from another Data Action, and part of that output is a list, it will only give you access to the first item of the list.