One big difference between Cygwin and the Linux subsystem is that Cygwin runs Win32 processes, under the Win32 subsystem, so the entire Windows API is available to you. The Linux subsystem (like the Subsystem for UNIX Applications before it) is a separate set of concepts on top of the raw NT system calls, so you get a GNU/Linuxish API instead of the Windows API. With Cygwin you get a GNU/Linuxish API as well as the Windows API.
See, for instance, this discussion about how copy-on-write fork is available as a system call (and had been around for a while, to support SUA), but doesn't work right with the Win32 subsystem, and that means Cygwin can't use it:
The Linux subsystem also runs unmodified Linux binaries-- with WSL, you can (theoretically) run any piece of software compiled for 64-bit Linux, which gives you access to everything in Ubuntu's package manager (Ubuntu's the only distro they ship right now). With Cygwin, programs have to be recompiled for Cygwin, which means you're restricted to programs that are either already in Cygwin's package manager or that you can compile yourself.
As you mention, WSL also isn't stuck with the restrictions that come from Win32 compatibility. One of the big impacts of this is that fork() can be faster (although I'm not sure if it actually is right now) than the mess that is Cygwin's emulated fork(). There are some more subtle distinctions, too, though: for example, WSL maintains Linux's conventions around locking open files and has full case-sensitivity. Cygwin doesn't even try to simulate Linux's behavior for either of those; it maintains Win32's behavior.
>With Cygwin you get a GNU/Linuxish API as well as the Windows API.
Genuine question, why is that useful? Intuitively, it seems like if you ever used that capability, you'd end up with a horrible chimera program that can't run on linux or windows, which doesn't seem good.
Well, the chimera program can totally run on Windows; it just uses a particular DLL for a good chunk of it's runtime. That's not super different from, say, a C# app with some native Win32 code, right?
A couple of plausible scenarios:
1. You have a legacy UNIX app that is now only being used on Windows, but rewriting it entirely is a giant project. You can compile it against Cygwin, and then new development can run on Windows.
2. You have a cross-platform app that needs a few OS-specific things in certain places. Maybe it's some sort of system status checking/auditing tool, maybe it interacts with hardware drivers, etc. You can use #ifdef WIN32 and call Windows-specific APIs, just like you can use #ifdefs to check for Apple-specific or Linux-specific APIs, and you don't have to port your entire app away from the UNIX model.
See, for instance, this discussion about how copy-on-write fork is available as a system call (and had been around for a while, to support SUA), but doesn't work right with the Win32 subsystem, and that means Cygwin can't use it:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-U...
I don't know how many actual applications take advantage of this, though. But if they do, then Cygwin is definitely not obsolete for them.