OK! Sorry for not investigating further, once I found the mailing list thread that seemed like it terminated with the proper fix (and verifying it fixed it for me) I stopped debugging the issue.

It is now clear.  I think this relates to the MSYS2 variable MSYS2_ARG_CONV_EXCL  which controls what is or is not escaped.  By default msys tries escaping any and all command line args with slashes thus leading do the cmd //c fix in use.

Of course once you start trying to do a large variety of program calls MSYS2 escaping causes more errors than fixes.  MSYS2 resolves this by using MSYS2_ARG_CONV_EXCL to specify what patterns should not be escaped, but if you are like me (and I am guessing the person who originally posted to the ML) you might just do MSYS2_ARG_CONV_EXCL="*"  to turn of escaping all together.  Now there is the problem that libtool has those built in hacks to get around the msys2 limitations but msys2 won't be escaping it leading to the literal //c being passed to cmd.exe causing this hang.

The best solution here may be for libtool to unset MSYS2_ARG_CONV_EXCL prior  to executing a cmd shell thus guaranteeing the brute escaping it expects.

Personally I think getting to the other position (forcing all escaping off) is a better long term solution as you don't have to worry about any potential funky modification when making native calls.   MSYS2 and native Windows do share a path format that works for both in nearly all situations and that is:
c:/test/my/file.txt   virtually all msys2 and windows executables accept that without issue and there are no backslashes to worry about fixing.  It has the side effect that msys also won't try to do any path conversion on the way out.   There are a few limitations to this:
*) You need to make sure your paths are in that format, if you don't know if something is a path or not that may not be doable
*) If you are trying to pass a msys2 filesystem file to a native command the prefixing has to be done manually (ie something that is in the msys2 root like /etc/myconfig.conf needs translating to c:/msys64/etc/myconfig.conf ).


That may be a pipe dream not worth considering, and the first solution of setting the ENV var before the call may be the best way to go.

I will say I have been compiling a massive amount of foss software (https://github.com/mitchcapper/WIN64LinuxBuild) as close to native windows as possible from inside msys2 and despite having the escape fixes turned off this is the first time I have run into this problem.  Prior to disabling the automatic conversion though there were a good bit of issues.

No, it's wrong.
See https://sourceware.org/pipermail/cygwin/2021-June/248814.html