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.