What's the point of doing 2>&1 and checking stdtout for the error
message?
The great benefit is that it ensures that the expected and actual output lines match not only in content but also in order. When you have stdout and stderr output, one option is to first put all > lines followed by all ? lines. However, this often makes reading and understanding tests particularly difficult because it makes it unclear which of the statements are expected to produce the ? lines. A better approach is to interleave the > and ? lines to reflect the expected order. However, in that case there is still nothing that ensures that the order of one actual stdout line and one actual stderr line matches the order of the corresponding > and ? lines. If you initially get the order wrong, or if some later patch inadvertently changes the order, nothing breaks. By using 2>&1 on statements that produce stderr output, you ensure that all actual output lines do indeed match the stated expected order and that any future order change will break the test.
Isn't it at least a little useful to confirm that the
message is in fact printed on stderr?
It's true that with 2>&1 we lose this ability however I think that it's highly unlikely that any new code would emit errors or warnings on stdout. The functions to emit errors and warnings are wired to do it on stderr. And if someone proposes a patch that emits an error or a warning using an ad hoc mechanism, that would surely be caught at review time. It's even less likely that a patch would inadvertently modify an error or warning to now go to stdout, while on the other hand patches that inadvertently change how and when a particular condition is detected and signaled is much more likely.
Philippe