First there was OpenVZ, then there was LXC - which essentially allow running an isolated instance of the kernel (very much like BSD jails). LXC can be locked down with capabilities, kernel namespaces, cgroups, and allow for quite fine-grained isolation. But the focus of Docker is more on use ability: the equivalent of asking a process to sit in the corner and stare at the wall. It's an easy way to get a lot of unruly children to stop interfering with each other, if you have many corners. But they're kind-a-sorta still in the same room. Not chained to their desks, not blindfolded.

But generally, docker doesn't do all that much locking down - if you have the libc/code to do something in a docker container, you can in general do it. The layered fs is mostly like a chroot - it's safe as long as the kernel is safe, and then it's completely unsafe - if the kernel isn't safe. The flip side of this is that if you write a program/daemon that works on regular gnu/linux, it'll work (as long as you provide the needed library code) in a docker container. And docker helps focus dependencies, in particular data dependencies (the other tricky part of getting something to run in a chroot - where's /etc/shadow? Where's /etc/group etc)).

I'm sure we'll see Docker move in a stricter direction, as more people are wrapping their minds around isolation -- apart from the running under same kernel, LXC can do more. And we have things like rkt with kvm backend that takes all the hard work put into containers and magically(ish) transplants that to work with minimal vms.

Docker did/do(?) one thing: it didn't allow you to run Docker in docker (you need/needed to run a "privileged" container for that).

I'm not sure if that was as coherent as what you hoped for, but that's sort of what I tried to imply wrt design tradeoff.