Personally, when I read "OSX support", I thought that meant that there would now be containers with Darwin-ABI binaries inside them. So on Linux, you'd use cgroups for Linux-ABI binaries and a VM for Darwin-ABI, just as on OSX you use a VM for Linux-ABI (and presumably would use the OSX sandbox API for Darwin-ABI containers.)
This "native sandboxing for own-ABI if available, VM if not, and VM for everything else" approach would extend to any other platform as well, I'd think (Windows, for example.) I'm surprised that this isn't where Docker is going, at least for development and testing of containers.
(Though another alternative, probably more performant for production, would be something like having versions of CoreOS for each platform--CoreOS/Linux, CoreOS/Darwin, CoreOS/NT, and so on--so you'd have a cluster of machines with various ABIs, where any container you want to run gets shipped off to a machine in the cluster with the right ABI for it.)
Going that way would dilute Docker's value. Docker's promise is that you can build a container and it will always work; it won't mysteriously break in production or giving you installation headaches. To do that, your development environment has to be as close to the production environment as possible. Having a totally different ABI doesn't help with that goal.
Our priority in the short term is definitely to focus on the Linux ABI and making it available on as many physical machines as possible. This is the reasoning behind our current OSX support, and support for more platforms coming soon.
Longer term we do need to support multiple ABIs, if only because a lot of people want to use Docker on x86-32 and ARM. Having ELF binaries built on Linux isn't of much help if they're built for another arch :) So at the very least we will need to support 3 ABIs in the near future.
The good news is that it can be done in a way which doesn't hurt the repeatability of Docker's execution environment. Think of it this way: every container has certain requirements to run. At the very least it needs a certain range of kernels and archs (and yes it's possible, although uncommon for a binary to support multiple archs). It may also require a network interface to bind a socket on a certain TCP port. It may require certain syscalls to be authorized. It may require the ability to create a tun/tap device. And so on.
Docker's job is to offer a portable abstraction for these requirements, so that the container can list what it needs on the one hand, the host can list what it offers on the other, and docker can match them in the middle. If the requirements listed by a given container aren't met ("I need CAP_SYSADMIN on a 3.8 linux kernel and an ARM processor!") then docker returns an error and a clear error message. If they are met, the container is executed and must always be repeatable.
TLDR: ABI requirements are just one kind of requirements. Docker can handle multiple requirements without breaking the repeatability of its execution environment.
Your reply primarily addresses architecture support and the implications for pre-built payloads. But I think a more important concern is the fragmentation that would result if Docker attempted to natively support other operating systems. Consider that practically every Dockerfile starts with a Linux distro, and includes commands specific to that distro (e.g. installing packages with apt). Everybody assumes that the payload is Linux-based, and it all just works. How would it work if Docker also supported FreeBSD jails, Illumos zones, or whatever other options are up for consideration? Would the public registry of Docker images now be fragmented along OS lines? Or would Docker try to automagically smooth over the fragmentation by firing up VMs when the host and container operating systems don't match? In the latter case, would every Docker installation then require a working hypervisor?
Considering that the overwhelming majority of Unix servers are running Linux, I think it's better to say that Docker is Linux-based, end of discussion.
This "native sandboxing for own-ABI if available, VM if not, and VM for everything else" approach would extend to any other platform as well, I'd think (Windows, for example.) I'm surprised that this isn't where Docker is going, at least for development and testing of containers.
(Though another alternative, probably more performant for production, would be something like having versions of CoreOS for each platform--CoreOS/Linux, CoreOS/Darwin, CoreOS/NT, and so on--so you'd have a cluster of machines with various ABIs, where any container you want to run gets shipped off to a machine in the cluster with the right ABI for it.)