Perhaps, I should give a practical example to help understand the patcher objective.
I am a hacker of Final Fantasy 6 (snes version). I have already two digits of patches for this game. For now, forget it and think you are a hacker who wants to do improvements for this game. You searched RHDN and another sites for patches. In the end, you could get nearly 40 small patches. All of them add small improvements for this game and it should be nice if all of them could work together.
Suppose that your patcher doesn't check for applying patches in wrong positions of the rom and that the patches are all from different people. Some of them don't have any documentation.
The first factor for corruption is if the patch is aimed for a rom with or without a header. If the patch is aimed for a rom without the header and the rom has a header, it will apply the modified bytes in the wrong location. Similarly, the patch also need to be aimed to a rom with the correct version. If only one of them mismatch the rom version and the header/no header issue, the game will be corrupted and will be left unplayable.
The most dangerous factor for corruption is address collision. When you apply a patch, if the patch overwrite the bytes already written by other patches, the game will be corrupted. The second patch must no overwrite the first patch. The third must not overwrite the first and the second. The fourth must not overwrite the first, the second and the third. If the patcher doesn't give you support to check or avoid the address collision between the patches, you can only pray that the rom will not be corrupted after the 40 patches.
Also, patches aren't static by nature. They should be upgraded for better versions. Let's suppose you have successfully applied 40 patches without corrupting the rom and want to upgrade only one patch. If you don't have an anti-patch, your only option is to start from a clean rom and apply all your 39 patches again. Of course, the new updated patch will change their addresses and it may or may not be compatible with your 39 patches.
The dual patcher is aimed to avoid the mentioned issues. It avoids the address collision between the patches and the appliance of patches that are not designed for the rom. It can also safely apply and remove the patches from the rom.
What is the max file size?
Internally dual uses a four bytes unsigned integer (32 bits). It can store the max value of 2^32. For my final fantasy 6 rom with 3MB, it is more than enough. For target files in the giga byte range, the patcher won't work correctly.
What sort of memory am I looking at when patching, when patch making and is there compression involved?
Dual follows a different direction from standard patchers. Instead of focus in the creation of small files with high compression for distribution, dual focus in the patches management.
Traditional patchers only need to store the difference between the files bytes. Dual needs to store the original and the modified bytes of the files. It is the double of the size of the bytes a traditional patcher should store.
Dual doesn't have internal compression and it is unfit for the creation of smaller files with high compression for distribution. It follows a different direction.
You seem to be heading for generic, is there any chance of it being adapted for something console/format specific?
Internally, dual perspective is to work with file bytes. It doesn't recognize any specific format for consoles. The actual direction is to follow the generic approach and to avoid any specialization for a specific console format.