- inefficient use of resources resulting from functionality duplicated in both the hypervisor and the guest (e.g., two TCP stacks, two filesystem implementations, two schedulers, and so on). (That's why I asked about this in a separate comment.)
- inefficient use of resources resulting from the inability to dynamically share resources between VMs (e.g., memory and disk typically have to be statically allocated to VMs, instead of sharing a common pool the way processes within a single Unix-like system typically do).
- poor visibility from the hypervisor into the application (i.e., observability tools cannot typically cross the hardware-virtualization boundary).
That's just a partial list.
I think that's why you're seeing pushback from people insisting that these be called VMs rather than containers: they have all of the above downsides of VMs, even if the operating system surface area isn't that large.
[edited for formatting]
What parts of a machine do traditional data center VMs emulate that Hyper avoids?
What system functions normally supported by a guest OS will Hyper not need to support? (E.g., memory management, network stack?)
Shall we call hypervisor+kernel+Docker image VM? I don't think so. It never tries to give you a complete machine, neither a full OS. Personally I like "virtualized container". But the combination of these two words might be more confusing, given that whenever you see the word "container", you think of Linux container.