Docker has its own security nightmares and mis-designs -- for instance, are you using user namespaces? With LXC and LXD user namespaces are the default (and unlike Docker's design, they can use different ID mappings which blocks inter-container attacks). There are plenty of other missteps I can think of.
(I am a maintainer of runc and have contributed to Docker for a long time, as well as collaborated with the LXC folks.)
I assume you're referring to the OCI image format (not the runtime spec). This is because the OCI image format doesn't quite meet what they want for LXD -- in particular the whole layering design that OCI uses (which was inherited from Docker) is simply wrong for them. In fact there is a strong argument that the layering design doesn't even match what OCI really wants (it effectively embeds an optimisation for "docker build" into the storage format).
I am actually working on improving the current state of OCI images[1] by using a snapshot-based tree structure -- which will also solve many problems we have in OCI that are independent from LXD. But it is possible that the LXD folks would be more interested if the OCI format more closely matched what they need.
Though it should be noted that LXC has had an OCI template for several years now[2] (and it actually uses a tool I wrote -- umoci -- to extract the OCI image).
Yeah I am aware of the oci-template. I was mostly thinking of discussions like this[1] where Stéphane says there are no plans to support anything like that in LXD.
I find the distinction between "system containers" and "application containers" to be a bit arbitrary from a technical perspective. What does it matter what I'm running as PID 1? I find both system containers and application containers to be useful.
It seems like LXD would see larger adoption if it were easy to run docker container images directly (built into the LXD tooling).
(I am a maintainer of runc and have contributed to Docker for a long time, as well as collaborated with the LXC folks.)