If the volume of them is going to be such then what is the option for building a program to automatically do it, or at least do it and damn the fallout. Some said generic injection of cheat engines/RAM cheats into ROMs was not doable, until it was done. If you can point to a tool and say "use that" then it makes enforcement of the rule somewhat easier
Interesting concept! Unfortunately it's not likely to happen because there is too much mapper (about 200 of them), so there is 40 thousand possible types of "conversions". Of course, it's not possible to convert to a mapper who lacks the features of the original, so this limits this number severly, but still.
It is extremely hard to auto-detect mapper writes within a ROM, and replace them with other mapper writes as this is totally game specific. Yet, it is a very easy process once you have a working copy of FCEUltra debugger.
I suppose it would depend upon how it is framed -- nobody would question a rejection for a basic palette hack where I make sonic's shoes green
Honestly this is about the same level of complexity as a mapper hack, assuming your target mapper has all the desired feature. If you should hack in pseudo-features (like, get arround no fine CHR banking, or replace IRQs with timed code) then it can become extremely though. This is not the case of mapper hacks that has been recently submitted.
Another problem I know (by experience!) is that mapper hacks are likely to get rare random crashes. For example in a MMC3 target mapper, $8000 is written to by main code, then is interrupted, $8000 and $8001 are written to by interrupt code, it returns, and $8001 is written to by main code, switching in a bank in the wrong slot, resulting in a crash. It's easy for the hacker to release the hack without noticing this kind of bugs if he does not spend hours playing the hacked game, since in the original games, it wouldn't happen as writes were done by only one instruction.