I haven't worked with remastering issues since August, and, at the first glance, had little to add. Seems OK to me.

Entering this realm again now, I have some comments. Numbering not following the issues mentioned.

1. Using the seek parameter with dd ("sparse file") is obvious when one knows about it! It is not necessary to use a loop image for remastering on any file system, but I think it is good&reasonably safe practice to use it on NTFS partitions. Then, only one fixed file is modified, no block moving etc.

2. This method, with all the copying, may be unnecessarily complicated, but I think it is rather robust, and it works with several settings - it is agnostic wrt cloop vs squashfs, for instance. The new compressed image is created from an actual file system, and, therefore, any inconsistencies resulting from UNIONFS bugs/troubles etc, should have the highest chance of being ruled out. It has never failed in giving me the space I have expected. Beware, however, that space freed by purging one package may partly be filled up installing another, if they have common dependencies. And, it moves installed programs from persistent store (freeing up space there) into the compressed image, which of course leads to compressed image growing. To get everything in place, I typically have to repeat this process 2-3 times.

If creating isofs/squashfs from /UNIONFS, only omitting directories is totally safe, copying can of course be skipped, but for me, it is enough with just one single potential problem in the shortcut to use the longer and proven way.

Excessive listings to screen may be avoided by redirection?

Furthermore, with USB3, it's not that slow on external media, also good USB3 sticks may be used.

3. Making a new persistent image could be left to Knoppix, but I want to have an exact copy of my environment in the remaster, and for that, I need the /home and /var directories. The handling of /var in remastering may not have been optimal, since in my original 6.7.1, /var takes up 431 MB, and <10MB of this is currently in the persistent image. Files that probably will be modified should not go into the compressed image, for after modification both original and modified version will take up space, but possibly, a considerable part of 6.7.1's /var will be left untouched? I don't know.
A considerable amount of data in /var is the main reason the new persistent store is very far from empty, and in case very little modification of the remaster is intended, the modified /var could be compressed. In my use, there will often be a series of remasterings, so a lot could be updated.
Maybe space in the compressed image could be saved by only placing a stub in the compressed image, and have everything persistent?

4. I think it is good practice to make the necessary privilege level explicit, even if this implies script code sprinkled with sudo's. It's safest to work as an ordinary user. If root privileges are not needed for an operation, the sudo may of course be omitted, but I tend to retain it if the operation under some policies _could_ have required root access.

5. Loop device handling seems somewhat buggy to me, and in addition, the busybox tool versions used in Knoppix init are not fully compatible with standard tools. But as long as the job gets done, I'm not that much concerned with error messages etc. Also, using scripts for file handling allows us to throw in all kinds of functionality, like moving/releting/renaming existing files etc.

6. The main issue in remastering is not touched upon in these scripts : How to purge? And the second most important issue is not addressed either: How to ensure a complete&working selection of packages? A major problem is that package organization is constantly changing, so the procedures that worked with one Linux release may need modification to work with another. I set up a series of scripts to do the purging, and also try to automate the installations as much as possible.