App Container spec gains new support as a community-led effort

That's a simplification of the problem. Ubuntu packages are not made to be run on Debian and vice versa. Packaging formats are the tip of the iceberg when it come to the myriad of choice made by distribution, and the impact on a proper integration.

If the package was the only problematic part, upstream would distribute static binary and downstream users would jump on it. And the various attempts to fix the problem ( autopackage, etc ) would have worked fine.

It turn out that they didn't got any traction, so either the problem is more complicated than format, or that's not a problem big enough for anyone to justify the cost of changing.

So the same goes for docker images or anything, there is a lot more than superficial differences such as package format. Given that systemd nspawn is able to work with both docker and rocket, it should cause trouble.
Now, the way you compose image together matter ( ie, what overlay network do you use, how do you do discovery in a micro service architecture, what port you expose, etc ), the content of the image matter ( cf this often cited article : http://www.fewbytes.com/docker-selinux-and-the-myth-of-ke... ), how and who update the image matter a lot more than the format ( as summarized on http://www.vitavonni.de/blog/201503/2015031201-the-sad-st... ).

Heck, even the orchestrator will play a big role, from full featured ones such as openshift v3/kubernetes or mesos/aurora to more simplistic one such as the one shipped by docker inc.

So in the end, you will have incompatibilities. As long as people want to have the choice, and as long as it make sense from a resources point of view to focus on one single choice rather than supporting the matrix of combination, you run into that. package format, containers format, etc, it all go the same way since years and for years to come.