bash.exe unusual commandline parsing

If I understand it correctly, bash.exe is a Windows commandline-executable, that starts WSL's /bin/bash and forwards given arguments.
As on linux (and WSL) executables are started with an argument array, but on windows executables are started with a single CommandLine, bash.exe needs to split the given CommandLine into multiple arguments, that can be redirected to /bin/bash.
As bash.exe is a Windows executable, in my opinion it should split the CommandLine into multiple arguments using usual Windows rules.
However the rules that are used to convert the CommandLine into multiple arguments are quite different. Its very confusing, if almost all executables use these rules, but then Microsoft publishes a new executable that conflicts with those rules.

Expected results:

bash.exe should split the commandline like this

Actual results (with terminal output if applicable):

bash.exe uses strange own rules to split commandline, only partly compatible to usual rules.
At least the second of those examples fails, a\\b should stay a\\b and not become a\b:
In cmd:

C:\Windows\System32\bash.exe -c "xargs -0 printf '%s\n' < /proc/$$/cmdline" a\\b d"e f"g h

outputs:

/bin/bash
-c
xargs -0 printf '%s\n' < /proc/2/cmdline
a\b
de fg
h

( I use -c "xargs -0 printf '%s\n' < /proc/$$/cmdline" to print arguments, because to use something with $@ or similar, I would have to pass double quotes to bash, and as mentioned, I don't know how bash.exe parses those...)

Windows build number:
Version 10.0.14393 Build 14393

Start by reproducing the supplied cmd.exe invocation on the reported WSL build and compare each argument with the linked Windows command-line parsing examples. The issue is done when bash.exe preserves and forwards arguments according to those usual Windows rules, including the a\b case, and the behavior is verified with an equivalent argument-printing test.