@Demi @Rudd-O @brendanhoar : I have modified OP to point to comments that happened after. If you disagree with the short versions of your sayings, please correct me where I went wrong.
What I understand as of today is the deduplication would resolve (consensus is not here) our diverging use cases. demi would benefit of it (clones of qubes, clones of templates. Restore of templates and qubes (wyng backup restoration). Some of us are not cloning templates. There is not even consensus on the benefits of deduplication vs reflinks in this thread.
I understand that OpenZFS pool support would be a matter of simplicity vs current LUKS+VG+LVM to obtain similar results without current complexity.
I understand as well, from my reading, that VDO would add even more complexity to the current setup and would not be directly usable from Qubes perspective either (and from my reading VDO was unfit in documented use cases where it was applied in LVM not at at pool level, but I might have missed something).
So the conclusion as of today of this thread is that it is better to see Templates as being short-lived, with or without specializations. And if specialization is desired, salting them is the best avenue.
Same applying to qubes and qubes clones for specific use cases. I ten to agree here as well, most of my qubes are cloned for short-lived scenarios. And If I really need to keep track of a specific case, wyng-backup comes to the rescue here, where I personally prefer to have limited number of qubes and work scenarios in the pool, where my tracked states are deduped in my backups, keeping a really long trace of states and deduplications.
I would not see benefits here of keeping my fedora-34 template in pool and trying to dedup it. Of course packages would be completely, and all, be different with now fedora-36. But, I keep them all, deduped, in my wyng-backup. Yes, deduplication on send is expensive (Keeping all hashes to compare before writing instead of pointing to altready existing block for an existing block) is expensive, but doing those backups are offline; when needed. If I wanted to have quick backups, my usage of wyng-backup would change as well, and I would prune old states.
So basically, from that thread, as of today, my own interest for deduplication lowered a bit. Seing it as being deployed by default just vanished, where having it activated by users having similar use cases seems even questionable, if the guideline is to become knowledgeable of the requirements to have enhancements of having deduplication, vs becoming knowledgeable of salt and salting deployments.
Trying to resolve Qubes traditional use cases seem to result, most of the time in the realization that there is no such traditional use case
Still. I thought, from guidelines of documentation, that cloning and specializing templates was what everyone was doing. Like I said before, just deploying whonix-wk and whonix-gw would economize 1gb at install of initial template. And that installing fedora-36 today, and even salting the deployment to specialize templates (communication, proprietary, basic etc) will consume redundant (and deduplicable space) until fedora-37. Then applying salt recipes to specialize will consume lots of space until next release and so on.