The following is extracted from a post by Ray Donnelly, a MinGW-w64 contributor. It enlightens on the subject and is essential preamble to my question.
There are 3 systems, MSYS2 and 32-bit and 64-bit Native Windows systems. Each system has its own repository of software packages in the MSYS2 distribution. […] that is an important distinction between them. MSYS2 implements a POSIX-y FHS filesystem namespace and that’s very important for lots of things.
[…]
The MinGW-w64 32-bit and 64-bit systems are Native Windows software which are rooted at /mingw32 and /mingw64 respectively. It’s not like we replaced every Linux API call ourselves; most of the upstream projects do this work for us since they already provide Windows ports, but yes sometimes we have to do it. We also add special relocation patches to a lot of the software so that you are free to install the root the whole thing (e.g. C:\msys64) wherever you want. MSYS2 software doesn’t need these patches (since the Native Windows location is a hidden installation detail) but MinGW-w64 software often does.
[F]rom an end user perspective, there’s only 2 systems, MSYS2 and the XX-bit Native Windows one, and yes, some packages exist for both those systems. Specifically, MSYS2 exists to run development tools necessary to build Native Windows software, so if a build system needs an MSYS2 version of Python or Perl to operate correctly (because it assumes FHS or whatever) then we need to provide those packages. We never add MSYS2 packages without making sure there is a need for them. If you don’t know that you need the MSYS2 version of something, then install the appropriate Native Windows one instead.
An example of when you will need MSYS2 Python is if you try to use Google’s repo tools. This is because repo uses the fcntl Python module and that module only exists on POSIX-y systems. IMHO Python is doing a bad job of abstracting the OSes here and that’s a fundamental thing that a scripting language should do, and fcntl (and pyWin32) should not exist, but I’m not the boss of Python.
Fortunately, Pacman has dependency management and will install the stuff needed for whatever packages you are actually interested in.
GNU Autotools will never work well except via a FHS compliant system with a POSIX shell, and this naturally leads to other tools needing to exist in the same filesystem namespace, such as make, perl, m4, bison, flex etc etc.
Given Ray Donnelly post, what makes up a system is first and foremost the PATH variable, because, depending on directory priorities Google’s repo tools will be built with MSYS2 or MinGW packages.
In fact the shell script, which switches between MSYS2 and MinGW shells, exports the environment variable MSYSTEM with its argument mingw32|mingw64|msys and sources /etc/profile. The latter, in turn, sets the PATH based on the value of MSYSTEM. By and large for MSYS2 the PATH is
/usr/local/bin:/usr/bin:/bin, while for MinGW 64 it is /mingw64/bin:/usr/local/bin:/usr/bin:/bin, therefore running the gcc compilers will execute MSYS2 or MinGW version accordingly.
There are other minor env. variables too, for example MANPATH to read the proper manuals, once the proper binaries are called, or PKG_CONFIG_PATH to read the proper lib files, when building.
As regards, pacman it is not totally true that it is not affected, as from @David Grayson comment.
MSYS2 wiki vaguely affirms that:
Use msys2 shell for running pacman, makepkg, makepkg-mingw and for building POSIX-dependent software that you don’t intend to distribute. Use mingw shells for building native software and other tasks.
Ray Donnelly clarifies the things again in another post :
Generally speaking, you can use any shell for pacman, but you could run into some issues using mingw shells where depending on what packages you’ve installed into /mingw32 or /mingw64, the post install scripts of packages (which are arbitrary bash scripts) may end up running an unexpected mingw-w64 variant of a program. A concrete example of that would be ‘sed’. So running pacman from msys2_shell.bat avoids a class of potential problems (though we’d try to fix any that are reported anyway).
Summing up:
What are other significant differences determined by $MSYSTEM value?
The immediate significant differences are in the related values of the path variables identified by @David Grayson.
Are there any binaries that make a specific use of this variable?
It seems safe to say that there is no specific binary reading directly $MSYSTEM, but a great deal of software use/read the path variables above based on $MSYSTEM.
Is pacman affected by the subsystem?
Yes.