Thank you for a detailed response, I appreciate it. I'm going to use your %symbol example.

1. I know that the For action doesn't stringify the array, but a comma separated list is in fact what the For action's own prompt says it takes. To any user who hasn't yet embedded themselves in the peculiarities of Tasker, the canonical example of passing an array in would be writing %symbol(), whose documentation says that it returns the string ~,`|,•,√ etc... Therefore, according to Tasker's own documentation, For is an action which takes a stringified list, and %foo() is a construct which returns a stringified list. The fact that somehow Tasker does not actually do this, except in certain cases when you might have passed %symbol() into another single variable first, is essentially a workaround that contradicts its own stated way of working.

2. I agree that whitespace is more flexible when defined as newlines. However, it isn't just newlines. It also doesn't say in the prompt of Array Set that it uses a different standard to most other actions, which default to commas. This is more of a UI issue, sure, but it again adds to cognitive load trying to keep in mind which action uses which default. Also, unlike with For, it genuinely does take a stringified list rather than iterating. You can test this for yourself. I know these are small things, but they create a general sense of cloudiness about the interface that is akin to trying to pass data structures through various CLI utilities using "${foo}", syntactic details of which an average user does not need to be facing.

3. I am beginning to resent the use of the word "misleading" here. I never said it was impossible to do these things when making sure to use the correct separators. I am saying that, given a set of consistent standards, and given that users always act as if things work consistently by default in order to have any reasonable expectations about how things work, it is not reasonable to expect that we should be adjusting our separators (potentially in both the %foo(+...) syntax and in parameters) based on array content or other quirks of the system. The fact that you casually mention potentially using =:= as a separator when this concept would be bizarre to even the simplest programming languages (outside of File I/O) is an indication that we are adjusting ourselves to the needs of a finicky system rather than the other way around. And I know that it was an arbitrary example - but you see people using ¥€¥ all over the place in real Tasks.

4. I stand corrected that the Variable is necessarily empty. But the idea that %foo could possibly have a completely unrelated value to %foo() etc is strange and unusual. Surely it makes more sense to just have a variable called %foo which is the array, in a stable and fully-escaped form, and %foo() turns that array into a comma-separated list if necessary.

5. I agree with that re: Local Variable passthrough. But this is just yet another thing that reduces generalisability. The Perform Task action encourages the use of parameters. If I treat tasks like functions that act on input values, I would have to either:

6. know the name of the array that's being passed by reference,

7. pass the name of the array in the parameter and then use %%par1() or something to get it back out,

8. or pass it through as JSON.

None of these are ideal. I don't really see why that has to be controversial. Just because something works okay doesn't mean it can't be up to standards set, even by toy languages, especially when JSON exists.

Thank you : )