It has been a long time since I used a BSD in anger, but aren't jails pretty much a take-it-or-leave-it system? Docker containers are an aggregate of Linux namespaces and cgroups and can be manipulated in a pretty granular way. I can, for example, share a networking namespace between two containers to have one inspect the traffic of the other (and do so easily).

Not saying you'd want to do that, but my understanding is that this is part of a lot of the clever networking you see in orchestration systems.

FreeBSD jails have some flexibility. You can choose to pass through the host networking as-is, or pass a limited selection of ips; I think there's a way to have a more separated stack that that too, but I haven't used it. You can allow raw sockets or not, you can shield the processes or not, same with IPC.

I haven't had a need to have a jail inspect traffic of another, I suspect that might be tricky. However I've used them successfully as a lightweight alternative to a vm for QA/dev environments -- use hard links for the base OS to save space, and give each jail its own ip and you get fairly cheap multiple boxes. I've also used it them to contain statically compiled binaries -- TLS terminator runs without access to much of anything, if the next vulnerability after Heartbleed was worse, it would be a lot harder to escalate vs common deployment with OpenSSL linked into a webserver; similar with an environment running ffmpeg.

There are already so many Dockerfiles out there and guides based on them. Plus you get filesystem layering, the cgroups, process limits ... I have a feeling it would be possible to build a container system that's Docker API compatible, but uses zfs and jails under the surface. I think that's what the old "unmaintained" port did a few years back.