Your summary of #1 is uncharitable. Although we don't know the technical details of what Microsoft has actually implemented, their description of Window Server Containers applies equally well to containers on Linux.
"While the sharing of the kernel enables fast start-up and efficient packing, Windows Server Containers share the OS with the host and each other. The amount of shared data and APIs means that there may be ways, whether by design or because of an implementation flaw in the namespace isolation or resource governance, for an application to escape out of its container or deny service to the host or other containers. Local elevation of privilege vulnerabilities that operating system vendors patch is an example of a flaw that an application could leverage. Thus, Windows Server Containers are great for scenarios where the OS trusts the applications that will be hosted on it, and all the applications also trust each other."
I am not trying to be a downer, I already wait Windows containers for my work, we are planning to build a project out of it, however there is a difference: When a Docker container on a Linux host was able to escape the container, (around 0.8) it was considered a huge security vulnerability, but this text from MS is like they already accept there will be vulnerabilities because "they designed wrong" or "implemented wrong", this does not give a confidence to run untrusted containers, and that's why they implemented HyperV containers as well.
They accept that there is less resource isolation in a plain container compared to a virtual machine container.
With a plain container, any OS process that you see is the common host OS process - it is just projected into your container. Compromising the process is compromising the the process for all containers.
For security purposes there's a big difference between starting with access to everything and then trying to reign in processes, access, resources etc compared to starting with hardware isolation and then allowing some functions (e.g. management) to cross.
Microsoft is completely correct on this: Containers are not security boundaries. A security boundary would require very few access points with very specific security policies. That is not containers.
Hyper-V virtual machines, on the other hand, enjoy hardware level isolation and starts from the other end: Anything that should cross the VM boundary has to be explicitly allowed, as opposed to OS virtualization where anything is allowed until the projection disallows it.
For instance, a container could try to delay processing of callbacks from the kernel processes. It is the same process as the others containers, and a single malicious container could very well starve the others for resources.
Both have their uses. Plain containers offer higher density but less isolation, Hyper-V (or any other VM technology) containers offer lower density but higher isolation.
"While the sharing of the kernel enables fast start-up and efficient packing, Windows Server Containers share the OS with the host and each other. The amount of shared data and APIs means that there may be ways, whether by design or because of an implementation flaw in the namespace isolation or resource governance, for an application to escape out of its container or deny service to the host or other containers. Local elevation of privilege vulnerabilities that operating system vendors patch is an example of a flaw that an application could leverage. Thus, Windows Server Containers are great for scenarios where the OS trusts the applications that will be hosted on it, and all the applications also trust each other."