Since most of the occurrences you reference are by me, I feel I have to give an answer here, though I will mostly paraphrase @Gilles.

I've been using _list context_ vs _scalar/non-list context_ (better than _string context_ which can be confusing if not understood as non-list context) dozens of times since at least 2004 [on ](https://groups.google.com/forum/#!searchin/comp.unix.shell/%22list$20contexts%22%7Csort:date)[usenet](https://groups.google.com/forum/#!searchin/comp.unix.shell/%22list$20context%22%7Csort:date) or [unix.SE](/search?q=user%3A22565+%22list+context%22) most of the time in articles discussing the impact of leaving expansions unquoted in Bourne-like shells. I don't remember anyone requesting clarification as to what I meant by that before.

I've not used it in formal specification of any shell languages, that's just English text to help explain the shell behaviour to other persons.

That's not _official terminology_ though that's obviously inspired from `perl` official (in the documentation) terminology. I can't tell if other persons have used those in the context of Unix shells before me (though it's very likely they did), but certainly people have since. I don't claim ownership of that.

_list context_ (at least when I used it in the contexts I've used it) simply means contexts where the shell is expecting any number of elements. While _scalar/non-list/string context_ would be where only one (or a single string/scalar if you want) is expected, like in `perl`. In most Bourne-like shells, those list contexts are:

- simple command arguments (as in <code>echo <i>elements</i></code>)
- <code>for i in <i>elements</i></code>
- <code>array=(<i>elements</i>)</code> (and variant with `+=`)

Some shells have more like:

- <code>cmd &lt; <i>elements</i></code> (and variant with `<>`) in `zsh` which does something similar to <code>cat -- <i>elements</i> | cmd</code> (as in `nl < *.txt`, `nl < {foo,bar}.txt` but `nl < foo.txt < bar.txt`).
- <code>cmd &gt; <i>elements</i></code> (and variants with `>|` `>>`...) in `zsh` which does something similar to <code>cmd | tee -- <i>elements</i></code>
- <code><i>elements</i>() { code; }</code> in `zsh` to define one ore more functions at once (or nothing if _elements_ resolves to an empty list (though a literal `() { echo x; }` is an _anonymous function_)).
- <code>compound=(foo=(<i>elements</i>) <i>elements</i>)</code> or <code>matrix=((<i>elements</i>) (<i>elements</i>))</code> and so on in `ksh93`.
- etc.

In those contexts, typically, globs are expanded and you need to quote your expansions if you don't want split+glob (or just empty-removal with `zsh`) to be applied to them.

For instance, if you replace _elements_ with `*.txt` in the examples above, `*.txt` will be expanded to the list of txt files in the current directory.

If you're looking for an equivalent in the POSIX specification, look for the contexts where globs are expanded. POSIX, in at least one instance refers to that as a _context where field splitting will be performed_ (wording which was actually changed after [I raised issues with the previous wording to the Austin group](http://austingroupbugs.net/view.php?id=888))

The _scalar contexts_ would be the other contexts.

In

 scalar=*.txt
 case *.txt in...
 [[ -f *.txt ]]

`*.txt` cannot be expanded because the shell is expecting just **one** string.

As a caveat/limitation, those terms don't cleanly capture what happens in `cmd > *` or `cmd > ~(N)pattern` or `a=(); b=; c=(a b); d=*; IFS=:; e=a:b; cmd 1> "${a[@]}" 2> $b 3> "${c[@]}" 4> $d 5> $e` in shells like `bash`, `ksh88` (using `set -A` instead of `var=(...)` syntax) or `ksh93` (only when interactive with some), where it could be seen as another _list context_ except that only a list with one element is expected (with splitting and globbing working differently for some).