I think this might be tried:

1. On startup, if persistent not empty, copy persistent content to ramdisk, run with ramdisk. Otherwise, swap KNOPPIX.sq and KNOPPIX_b.sq, run from KNOPPIX.sq
2. During running, use two (script) commands: ramdisk_save and ramdisk_commit. ramdisk_save saves to a overlayfs mount of knoppix-data.img and KNOPPIX.sq, unmounting afterwards.
3. ramdisk_commit first performs a ramdisk_save, then compresses the overlayfs mount to KNOPPIX_b.sq, unmounts and clears knoppix-data.img.
4. Unless otherwise requested, KNOPPIX_b.sq will be renamed to KNOPPIX.sq and used at next startup, the old KNOPPIX.sq becoming KNOPPIX_b.sq and usable as a backup until next commit.
5. Cheatcode revert either aborts the swapping after a commit, or works with the oldest squashfs image available.

This way, we never use the persistence for daily work, we just save to it. There is not much complexity added to minirt init either: Copying and possibly image swapping, using noimage setup. With the revert cheatcode, KNOPPIX.sq and KNOPPIX_b.sq are swapped, if KNOPPX.sq is not already the oldest.

With FAT32 limits, this could be done within ca 12GB space if mksquashfs can use a pipe. Otherwise, ca 12 GB extra is needed for filesystem copy. When a 32GB USB3 stick costs about $20, I don't think an extra 16GB is that much to care about. I would guess ca 2GB persistent store would be fine with this setup, and starting from DVD Knoppix slimmed down to ca 3GB (example of purging procedure provided elsewhere), the should be enough workspace for many needs. Even when the least efficient squashfs compression is used.

And using NTFS or ext3 file system, the 4GB limit does of course not apply.