I think what I'm getting at might not be clear though - I'm not proposing a new format (I've seen enough of that on RHDN etc. over the years) but more just of a mental exercise. Like "how feasible is this" and then "what would the solution look like maybe?".
Well in my opinion as someone who is totally unqualified to comment on the subject, the ideal patching format would have a set of flags to operate on the rom (when moving existing data around) and to write to the rom (when overwriting) embedded in the patch with the data. Or maybe just a set of commands in one patch subfile, and the data to write in the other subfiles.
I'm not sure how you'd generate patches in a non-involved way though. It would be a programmers tool, the romhacking equivalent to esoteric bash utilities with their own built-in scripting languages. Obviously the tool to write the patch to a rom should be as non-technical-user friendly as possible.
List of commands might be:
* move(start address inclusive, number of bytes)
* move(start address inclusive, end address exclusive) //end address being exclusive seems to be the standard, but I don't like it.
* write(address, byte array identifier)
* delete(start address inclusive, number of bytes)
* delete(Start address inclusive, end address exclusive)
I think the thought was prompted by some of the comments I saw after my T-Edition patch went out, combined with my experiences after releasing the Mother 3 patch in UPS. I basically learned that 1. some people LOVE the IPS format, 2. some people will ONLY use the IPS format (they get confused and frustrated otherwise for some reason), and 3. some people expect the IPS format to just always work without understanding that it has technical limitations. Hopefully that makes sense.
Simplest solution is to find an open-source licensed GUI patching tool for the format you choose and distribute that with your patch.