In theory, one could build Darwin-based OCI images: the nix package manager does, in fact, build such images on macOS but there’s no platform to actually run them on. However, I’d really like this ability: the whole Linux VM overhead on macOS is annoying for development environments.
It's not hard to imagine that Linux binary compatibility might work out much better on macOS than it did on Windows, due to macOS already being a Unix. FreeBSD has been doing it forever, though I'm not sure what the current state is with regards to performance and completeness.
While true, the closer Darwin is to Linux, it simultaneously eases implementation while disincentivizing doing it in the first place. Rarely you want to run a prebuilt standalone Linux binary on macOS; you just compile it to run on Darwin. In cases where you actually want Linux, you probably don't want even the slightest edge cases to be present.
Besides, VMs are quite fast if you have hardware support.
Running docker provides that incentive.
No matter how fast VMs are, they are still quite a jump from just running local processes, e.g. they consume resources while idle.
Also,.having to rebuild your binary just to run it under docker/linux means you cannot benefit from your compiler cache you just used minutes ago to run your unit tests locally (e.g. if you use tool chains like go or rust that do use compilation caches)
Microsoft gave up on the syscall-emulation approach mostly because of filesystem performance issues - WSL1 uses the host NTFS filesystem for everything whereas WSL2 uses a backing ext4 disk image, which means that as long as one stays in the "Linux world" the performance is way better.
