A Container is like a Hypervisor, but instead of hosting a full-OS VM, the Container holds a Docker, which is just the code and data. Containers are similar to Application Pools or SQL Instances, and there are "Container Databases" which are much more self-contained than the traditional database. Containers depend on the Container OS for binary files, frameworks, and DLLs.
I like to look at it as a spectrum: Bare metal - Virtual Machine - Container
At one end, you're both running the binaries and scheduling threads. In the middle you're running binaries but not scheduling threads. On the other end, you're depending on the Host to do both.
[1] https://www.joyent.com/developers/videos/docker-and-the-futu...
[2] http://www.slideshare.net/bcantrill/docker-and-the-future-of...
What lx-brand zones do is present an alternate system call table to the binaries executed inside the zone. Those "lx" calls are compatible with the Linux system call table and get mapped and/or translated to illumos kernel system calls. Binaries don't know the difference.
I guess it's briefly described as a multi-tenant container system that isolates tenants by grouping them into parent containers? Maybe?
The containers don't run a different kernel. They're just regular processes, in an fancy evolution of a chroot jail.
If you want to run something like Windows or FreeBSD, then you break out QEMU.
But the real question that should be at the top of the file, or at least that table of questions, is "what is a container"?
So: what is a container? (As opposed to a VM.)