one important thing I just have thought out is that
If one of the design goals is "to avoid snapshotters to mount filesystems theirselves", so that "mounts[] will be passed to mount handlers to parse".

If my understanding above is correct: I guess loop should not be decided by the snapshotter itself since (take EROFS for example):
[runC] for linux versions without file-backed mounts (typically Linux < 6.12, but I think we should also consider this feature could be backported to old downstream kernel versions): we should try to mount files with file-backed mounts, if -ENOTBLK is returned, use loopback devices; also see util-linux mount logic:
https://github.com/util-linux/util-linux/pull/3317/files#diff-ae74bd215cd470d68e72bf40ebc5f300c9aa5a2f9f1b0ed8ca8b4d519b25ebc6R1088
[runC] for linux versions with file-backed mounts: we should try to mount files with file-backed mounts, it should mount succeed;
[secure containers like Kata]: we should use virtio-blk to pass through files rather than generating loops too;
[gVisor]: they should mount files directly.

So I think the same file should be handled according to different shims, like runc-shim and kata-shim, etc.

And the file might be better to be parsed as:

[]mount.Mount{
   {
           Type: "erofs",
           Source: <fsmeta>
           Options: []string {
                "device=<layer0>,device=<layer1>,...,device=<layern-1>
           }
    },

, , ... are all files, it's up to mount managers to decide how to setup devices to mount these....