I’ve noticed that the exercise talks about
Wouldn’t it be better if everything is changed to ‘arrays’ for consistency and less confusion? This issue has previously been mentioned here Use of "list" vs. "vector" in Clojure Flatten Array exercise instructions
problem-specifications/exercises/flatten-array/description.md at 763564e1763eba4f03c4a6846933f34e2fa8aff6 · exercism/problem-specifications · GitHub doesn’t seem to add any additional clarity. That’s where list-like structure is used, and it’s ambiguous what that even means. List-like in what way?
Since array is in the exercise name unfortunately, I think we should use array in the description for consistency and add appends to clarify what’s being used. Pyret has an append already because arrays and lists are handled very differently by the standard library. Arturo needs an append currently because lists don’t exist and we use lazily evaluated blocks. If we switch to just saying arrays, I can change the blocks to eagerly evaluated arrays easily and no append is needed.
Python will have to instruction append this as array.array in Python is for numeric data only, and most Python programmers don’t even know about it.
But also? Most Pythonistas sub list when they hear array anyways … so.
Just re-read these instructions. I think they need more than “array” normalizing. The code example implies arbitrary nesting depth and heterogeneous data — which may or may not be how arrays/vectors/lists/whathaveyou are implemented across programming languages. 
For example:
input: [1,[2,3,null,4],[null],5]
output: [1,2,3,4,5]
The example to me implies a fixed nesting depth instead. A tweak like [1,[2,3,null],[[null,[4]],5] indicates the arrays won’t have a fixed nesting depth.
Whelp. Not sure if we should tweak it or not. The canonical data does seem to mostly stick to numeric data. But this test case has 5 levels of nesting.
This one has 6 levels with nulls (which the notes say not all languages implement).
I’m tempted to suggest this moves in the other direction and adds, say, a mixed-numbers-and-strings data … but that might not be feasible in some tracks :D
For Python, we may want to add both an addendum and additional test cases that include other types of nested data, since that’s how lists are often used in the language.
But for canonical data, I don’t think that will work for many languages, depending on their array implementation.
In this case maybe we can expand the description to mention that null-like values depend on the language, and the case of heterogeneous data, and also point the reader to the test suite?
I was thinking something this:
Take a nested array of any depth and return a fully flattened array.
Note that some tracks may include null-like values in the input array, and the way these values are represented varies by track. These values should not be present in the flattened array.
Additionally, input arrays may or may not be homogeneous, depending on the track.
Check the test suite for details.
input: [1,[2,6,null],[[null,[4]],5]
output: [1,2,6,4,5]
I think those might be good improvements. 
I don’t want to belabor the point or make it all about languages that have dynamic array implementations — but maybe something along the lines of:
Carefully check the the tests for more detail. Input data could be nested at more than a few levels. Depending on your language implementation, the data could also include null-like values, mixed data types, or multiple "empty" arrays.
Or maybe not even that much detail. Just … something to at least poke students to think and to look, rather than making assumptions based on the word array or list or …
Apologies! I was typing when you were typing. 
I like that! I think we are largely in agreement. I would tend to stay away from the word homogeneous tho - in my experience, it often confuses even some native English speakers. So I might have a preference for “mixed (or different) data types” vs “data of all the same type”.
Or use the word, but put a definition in parens. Either works.
Okay, so what about the test descriptions then. I think the common approach is to deprecate the old ones?
Do we actually need to change the cases/data — or do you mean the annotations in the file?
Generally, when we need a new or changed case, we depreciate the old one and then add a new reimplemented case. But if the case itself (data and expected results) is not changing, I am unsure if we really need to deprecate and reimplement.
Ah! Just re-read the canonical data. Yeah. Those notes are actually in the description field. That does imply we have to reimplement them.
Okay, here we go. First draft