It's a bit surprising that they dismissed qcow2, because it does exactly what they want. It's also pretty easy to implement in a vm. The file format is a 2 level page table per snapshot, with pointers to blocks. I suspect they didn't really look at it enough.
Here's the implementation I did for openbsd; it's around 700 lines, including the gunk to interface with the hypervisor.
It's not a good choice for computing diffs, but you can run your VM directly off a read-only base qcow2, with all deltas going into a separate file. That file can either be shipped around or discarded. And multiple VMs can share the same read only base.
So, it probably would have been better to write the code for the hypervisor, and end up with something far more efficient overall.
Not entirely sure of their reasons but their main stumbling block was that they wanted snapshots in-VM, that seemed a bit like a counter-intuitive considering that part of their reason for a VM to begin with was to ensure security.
When working with microVM's, which I'm assuming Cognition is doing, you don't have the option of doing qcow2. Raw disks as either block devices or files is all you've got.
Qcow2 is great for use with vms but I think is actually underrated otherwise.
I use it to back up external disks, usb sticks etc. Because the resulting qcow2 images are sparse and compressed they use less storage which is great for backups.
Here's the implementation I did for openbsd; it's around 700 lines, including the gunk to interface with the hypervisor.
https://github.com/openbsd/src/blob/master/usr.sbin/vmd/vioq...
It's not a good choice for computing diffs, but you can run your VM directly off a read-only base qcow2, with all deltas going into a separate file. That file can either be shipped around or discarded. And multiple VMs can share the same read only base.
So, it probably would have been better to write the code for the hypervisor, and end up with something far more efficient overall.