MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.
I'm not quite sure which capabilities this should be. The copper writes a value into a register - that's really it, it did not become more capable on AGA.
However, this aside, the problem is not even MrgCop(). The problem is that the system creates copperlists in one way, and then has a couple of extra functions that "poke" on the created copperlists, bypassing the regular copper list creation functions. This is particularly tricky for the copper "wait" functions as several (hardware) copper instructions need to be combined to make up a wait for an arbitrary position. Unfortunately, these "other" functions expect for that a particular form of the copper lists.
So we have two (actually even three) sets of functions that operate on the copper lists. Partially in C, partially in assembler. One abstract "copper list built-up function" aka MrgCop(), to which CMove and CWait() also belong, and the SetColorMapXX() functions (poke directly into the copper list) and the VideoControl functions, which also directly poke into the existing copper lists - both bypassing the abstraction layer. Changing one makes another one explode in your face.
As a side remark, Os 3.1 had exactly in this mess a bug: If you had a productivity screen and a workbench hi-res screen, and a 35ns sprite on the productivity screen, and a 70ns sprite on the workbench, and you closed the productivity screen, graphics would have scrambled your memory. The sprite size adjustment tried to "poke" an already existing copper list (instead of using the proper abstraction), but the copper list it referred to belonged to the screen that was just being closed, and thus was already released memory.
The biggest problem with MrgCop and its macros and support functions is that it doesn't and cannot sort blocks into the order that they are supposed to go in. If you are using dual-playfield mode and color changes for the sprites, for example, trying to get all the copper instructions to line up with both playfields and 8 other moving objects requires sorting, not just merging. One hardware banging engine written in C uses a "blocks mode" where the first instruction in a block is a copper wait and all additional copper move instructions are after it in a form that resembles Chomsky Normal Form. This allows all the blocks of copper instructions to be properly sorted with minimal overhead.
This allows the "infinite vertical scroll wraparound" that uses the modulo register to make the bitplane pointers all jump to the top of the buffer when the end is reached with a negative signed addition and then reverts the modulo register the next rendered row of pixels. It's only 2 waits and 2 moves but they aren't always in the same order when you do it on both playfields.