Some notable changes are:
- It has its own package repository, using PKGBUILDs on github. It can also be updated from within its own shell. Cygwin doesn't do this, for very important reasons, involving autorebase hell which MSYS2 is certainly still subject to.
- In their fork of cygwin1.dll, they removed support for symlinks (i.e. `ln -s` creates a full tree copy); and the /cygdrive/ root directory was replaced with / (just like the old/deprecated MSYS1).
- It has three startup links, in which gcc/ld/make and the like are all "symlinked" to different versions (e.g. targeting win32, targeting win64, or targeting MSYS2 itself). It makes it easier to compile software targeting windows. You should install separate -devel packages for each "environment".
- MSYS2 focuses on packaging dependencies that would be useful for compiling software targeting the Windows platform (e.g. libXYZ). In comparison, Cygwin is more of a mini-OS, packaging applications for general use (e.g. rsync, BIND, MySQL and X11). There is a lot of overlap, but many exclusive packages.
- MSYS2 is amenable to merging back with Cygwin, but, the patches they've made to cygwin1.dll can't be upstreamed. Cygwin proposed a new plugin system that would allow MSYS2 functionality within Cygwin, but, nobody has done the work to port MSYS2 to this new system. (maybe outdated information)
You can explicitly include it if you need the POSIX compatibility parts missing from Windows, but most software doesn't.
The 'msys2' software repository (as opposed to the 'mingw32' and 'mingw64' ones) contains things that link to msys-2.0.dll which is GPL, and yes it includes compilers and linkers that in turn generate new PECOFF objects that in turn link to msys-2.0.dll. This repository exists mostly as build scaffolding (Autotools, bash) to support building native Windows software (as exists in the other two repositories) and that is the real goal of MSYS2. If you want POSIX-y GPLed software on Windows, use Cygwin.
You are right to caution people on the naive usage of our msys2/gcc package, but you've made it sound like something much worse than it is.
We didn't remove support for symlinks, you can enable them in the MSYS env. var winsymlinks:nativestrict if you want. If symlinks didn't require special permissions, we'd enable them by default, but unfortunately they do. Maybe one day Microsoft will change their minds on this. I can only hope so. I guess you may have meant that we don't create the 'Cygwin special' symlinks that winsymlinks:native falls back to when it doesn't get permissions? Yes those are an interoperability disaster for MSYS2 when native programs read them.