My preferred schema: PD at the qube level, hot-swapping at dom0 level…
When Qubes is installed it setups an encrypted space allocated for PD (whether user uses it or not).
When user sets up a Qube they can flag it to be included in the PD layer if PD is active.
From dom0, user can hot-swap into PD layer via a hotkey + creds (activate PD layer). Depending on the creds entered the PD layer vault space is decrypted to the outer or inner layer (Like Veracrypt). Qubes flagged to be included in the PD pool are now bound to the PD layer vault space.
It needs to be setup such that once qube is setup, bad actors could not know if the qube is included in the PD pool.
This would allow for qubes to run in parallel… some in PD… some in overt layer… leaving plenty of red herrings.
Ideally more than 2 passwords could be surrendered to bad actors (meaning PD space could have 3 or more passwords, taking to different layers).
.
The sandboxed architecture of Qubes seems it would adapt well to PD at the qubes level.
We already have working implementations with Veracrypt. Qubes 4.1 already has storage pools. Now it just needs a PD layer vault space setup by default when installed, so all Qubes installs look equal. And then some rails to decrypt and bind to the PD vault when hot swapped.