Unless something has changed since I last looked at it, cosmopolitan depends directly on the host's raw syscall interface everywhere but Windows (on Windows, it correctly dispatches syscalls through supported userspace libraries, e.g. `kernel32.dll`).

This is unsupported, undocumented, and unstable on every target cosmopolitan supports other than Linux — macOS and (Free|Net|Open)BSD define their syscall ABI as private and subject to arbitrary change, and they do change it. The only supported syscall interface is via their userspace libraries, and binaries that target the syscall ABI directly will fail on future releases.

Furthermore, while cosmopolitan binaries are multi-arch (amd64/arm64 currently) and multi-OS (Linux/Windows/macOS/...), they are arch-specific and OS-specific. Once support for a new target has been added to cosmopolitan, existing binaries must be rebuilt to include it; existing binaries cannot run simply by porting a common runtime.

On top of all that, the APE executable format relies on ill-defined fallback heuristics — which may or may not be implemented by a shell — for executable files that fail with ENOEXEC after first calling `exec()`, but look like they may be '#!'-less shell scripts. Unsurprisingly, this is unreliable, depends on the user's shell, and means that programmatically executing an APE executable using `exec`, `posix_spawn()`, etc, will simply fail.

Cosmopolitan is neat hack, but it's not a viable multiplatform executable format, runtime sysytem, or distribution mechanism. Something like WASM + WASI seems much more likely to fulfill this function in the future.