Incorrect passing of argc argv with multiple redirects

[Morgan McClure]

So I think I've discovered a bug with the way that bash handles passing
argc and argv to programs in the presence of multiple redirects.

For this testing, my C source file is just the following:

int main(int argc, char * argv[]) {
    return argc;
}

For the purposes of testing, I comment out one or the other of those lines
and run the following:

./a.out; echo $?
    returns 1 as expected
./a.out foo; echo $?
    returns 2 as expected
./a.out foo > /dev/null; echo $?
    returns 2 as expected
./a.out foo > /dev/null 2&>1; echo $?
    returns 3 NOT as expected

If I modify and recompile the program to return the contents of argv I can
see that the contents of that 3rd argument is the string "2".
This behavior was tested and not observed with zsh and seems dangerous
(since a program taking variable length arguments might behave differently
only when the user tries to silence output). I could /maybe/ see an
argument for it being the string "2&>1" but "2" is very much incorrect.

I've tested on:
OSX 10.14.6 with the provided bash shell:
    "GNU bash, 3.2.57(1)-release (x86_64-apple-darwin18)"
as well as latest from brew:
    "GNU bash, version 5.0.7(1)-release (x86_64-apple-darwin18.5.0)"

Also reproduced on CentOS:
    "2.6.32-504.30.3.el6.x86_64 #1 SMP Wed Jul 15 10:13:09 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux"
    "GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)"

Is this known behavior? I've been unable to locate documentation to this
effect and it seems highly unexpected especially given that other shells
don't appear to do it.

-Morgan