What's the difference between WSL, SFU, SUA/Interix, the POSIX subsystem, and Cygwin

Regarding SUA/SFU and Interix, there's a difference. Wikipedia explains it pretty well and extensive: Microsoft POSIX subsystem and Interix

Interix was a BSD implementation on top of the POSIX subsystem. You could replace it with another implementation like a GNU Debian or NetBSD (which was done). SUA (2005) opened up the POSIX subsystem so you could extend it with NT calls and even run mixed Posix/Win32 applications.

Unfortunately Microsoft never released suitable development tools and even outsourced the support. There were a forum where users could help each other out with development and other things. The support company supplied a repository with a wide range of binary packages. Eventually Microsoft stopped funding and pretty much all info about Interix disappeared when the support company closed down the forum.

In short: The SUA Posix applications were very fast, probably the most efficient you could run on Windows. But they were a pain to develop, involving hacking into NT and Posix system files, ie a lot of fun.

Interix/SFU/SUA is a lightweight subsystem, replacing only the userspace Win32 layer with something like a Unix libc – even though there is a "subsystem driver" (psxss) for certain tasks, it still uses Windows PE (.exe) executables, the libc still uses NT kernel syscalls, Interix processes look almost entirely like Win32 or native processes, and they have the same filesystem access.

Cygwin is similar but simpler; it's built entirely as a userspace runtime library on top of Win32 (with the occassional NT call). As a result, Cygwin apps are really just Win32 apps which use a really weird libc.

In comparison, WSL is much more extensive than even SUA – the Lxss driver reimplements Linux kernel syscalls rather than userspace library functions, and can run unmodified ELF binaries (the default WSL system is stock Ubuntu). The WSL environment is mostly self-contained and is practically a "User-mode Linux" virtual machine, with very little interaction with the host OS. Although WSL processes show up in the shared process tree, you can't just run /bin/sh directly – you have to boot the entire WSL system, which is done by bash.exe behind the scenes. (There was a blog post about that.)