CimFS-backed overlay mount performance parity with Linux overlayfs for container image layers

No files, tests, or implementation entry points are identified. Start by locating the CimFS layer-composition and Windows container storage code, then review how writable and read-only layers are mounted; done requires measurable copy-up, shared-page, and cold/warm container-start benchmarks against Linux overlayfs.

Is your feature request related to a problem? Please describe.

Windows container image layers are still fundamentally VHD/reparse-point-based even where CimFS is used for the read-only layer store, whereas Linux containers get true union-mount semantics from overlayfs: cheap copy-up on first write, shared page cache across containers referencing the same read-only layer, and near-instant layer composition at container start. In practice this shows up as:

1. Slower container create/start times on Windows nodes relative to Linux nodes for images with deep layer stacks, because layer composition still involves more filesystem-level setup work than a Linux overlay mount.
2. Weaker read-only layer page-cache sharing across containers on the same host — multiple containers built from the same base image don't get the same "one copy of the base image's pages in memory, shared by all instances" behavior Linux gets from overlayfs + the page cache, which hurts density on nodes running many containers from a common base.
3. Copy-on-write semantics on first write to a layered file are less predictable/performant than overlayfs's copy-up, which affects any workload that writes to files inherited from a lower layer (package managers, log rotation into inherited directories, etc.).

Describe the solution you'd like

• Extend CimFS (or a successor) to provide true union-mount semantics for the full container layer stack, not just the read-only base — i.e., an overlay driver where upper (writable) and lower (read-only, CimFS-backed) layers are composed at the filesystem level with overlayfs-equivalent copy-up cost, rather than today's per-layer VHD/reparse composition.
• Guarantee that read-only layer pages are shared in memory across all containers on a host referencing the same layer, verifiable via a documented/measurable metric (e.g., working-set pages attributable to a shared layer vs. per-container private pages), so this is testable rather than an implementation detail nobody can confirm.
• Publish container create/start latency benchmarks (cold and warm cache) for a representative multi-layer image (e.g., a typical .NET or Node base + app layers) versus an equivalent Linux overlayfs container, so parity progress is measurable release over release rather than anecdotal.

Describe alternatives you've considered

• Silo/container pre-warming (create idle, attach on demand): mitigates start latency for high-churn workloads today, but is a workaround at the orchestration layer, not a fix to the underlying layer-composition cost — and it doesn't help the memory-sharing/density problem at all.
• Sticking with current CimFS-for-read-only-layers-only: is already an improvement over the older VHD-only model, but doesn't close the gap on writable-layer copy-up cost or on measurable page-sharing guarantees, which is the part of this ticket that most affects density.
• Recommending larger, less-layered images to reduce composition cost: works around the problem for individual teams but doesn't scale as general guidance and goes against standard container image-layering best practices that exist specifically to maximize layer reuse.

Additional context

Filed as a follow-up to #[syscall/capability filtering ticket https://github.com/microsoft/Windows-Containers/issues/649] and #[PID namespace ticket https://github.com/microsoft/Windows-Containers/issues/650], same feature/performance parity-with-Linux-containers effort. This ticket is scoped to layer composition and memory-sharing performance; the separate, harder problem of host/container kernel-version lockstep (which also affects image portability, not performance) is intentionally out of scope here.