One, it might be totally fine to run macOS binaries! If your code is portable to macOS and Windows, you might still want to use Docker for dependency management, network isolation, orchestration of multiple processes, etc., but you might not care what the actual host OS is. (Just like how people are interested in running ARM binaries, even though Docker started out as x86-64.) At my day job, all the stuff we put in Docker is either Python (generally portable), Java (generally portable), or Go (built-in cross-compilation support). It's absolutely sensible to do local dev on a Mac and then deploy on Linux in prod - it's perfectly sensible to do so without Docker in the picture, and plenty of people do just that.

So, maybe all the people you're yelling at understand the concept you think they don't, and they're okay with it.

Two, it's not at all true that to run Linux binaries on non-Linux, you need a Linux VM. WSL1 is an existence proof against this on Windows, as is the Linuxulator on FreeBSD, as are LX-branded zones on SmartOS. Linux itself has a "personality" mechanism for running code from non-Linux UNIXes. You could do the same thing on macOS, and teach the kernel to handle a good-enough subset of the Linux system call interface - it would be far less work than adding containerization (namespacing and resource isolation) in the first place, so I'm not sure why you're so hung up about this.

> Two, it's not at all true that to run Linux binaries on non-Linux, you need a Linux VM.

So (a), this entire thread, the entire post, is about docker. (b) WSL1 worked so well, Microsoft not lonely abandoned that approach for WSL2, they also never used that approach for containers on Windows. Hence, Windows native containers are, drum roll... Windows.