This is a fairly speculative feature request, since it almost certainly requires OS-level support.

I was reminded by discussion in a containerd PR that the current best-known (by me...) approach to do a read-only mount of a committed WCOW container image on the host is to mount it as a read-write mount with a small-as-possible sandbox/scratch VHDX, and then discard that VHDX at the end.

Although workable, this suffers from two issues:

• Anything that tests the readonlyness will see a read-write layer; although this is a documented-valid implementation, the containerd Snapshotter test suite doesn't currently agree.
• We're spending time on VHD manipulation/mounting needlessly.

So the request is that either AttachLayerStorageFilter gain a parameter, or a new API be introduced, that would in-effect take just a layerData structure, with no layerPath, and resulting in a mountable volume GUID or whatever AttachLayerStorageFilter actually produces... (See #1076 where I documented that I have never used AttachLayerStorageFilter successfully, so am not totally sure what the expected flow is).

Looking at the user-space WCIFS and Bind Filter APIs introduced after RS5 (which I learned about via #1462), the tools for this might already exist at an OS level, in Windows Server 2022, if I'm guessing correctly that a Bind Filter merged mapping is the same as a WCIFS layer stack.

The other reason this is speculative is that I don't have a concrete use-case for this apart from "the containerd snapshotter tests this". I suspect BuildKit's COPY --from=<some_image> will hit this code-path, though, from minimal code-tracing efforts, as it relies on host-mounts, which is how that PR got started in the first place.