In short: no. MOSSYS isn't there to allow you to replace MorphOS components.

Longer response: MOSSYS:C has priority over C:. This is also the case for example LIBS: and DEVS:.

What this allows, however, is to have components and/or commands added that do not exist in MOSSYS, without disturbing MorphOS internals, and have these user changes persist over MorphOS system upgrades.

Here's some background from nearly 20 years ago: The very first MorphOS versions didn't have the concept of MOSSYS, but instead used .elf file extension for native components. For example the system would load a library with .elf extension before trying to load it without the extension. This quickly became a problem with multiassigns, as then non-PPC component would get picked if it existed in any of the earlier directories of the multiassign. This resulted in the wrong (68k component) being picked up instead of the native one.

The concept we came up to fix this was to separate PPC native components to a completely separate directory (SYS:MorphOS) and then have MOSSYS: assign assigned to it. Then we modified the system to attempt to load the components from MOSSYS: first, and only after if that fails try SYS:.

As a happy coincidence this also gave us nice separation of "system" and "user installed" components. If I recall correctly this wasn't the initial intent, but kind of a byproduct of this fix we came up with.

Now the actual beef of this story:

Because of the original intent of the MOSSYS, we really don't support replacing things that already exist in MOSSYS. If you really want to do that you need to disable the component in MOSSYS manually (or put your replacing thing in MOSSYS direct, overwriting the system provided one).

This is not recommended or officially supported by for example the MorphOS upgrade script. But if you do this, you need to keep track of things you've manually poked and make sure things continue work as you have hacked them after the OS upgrade.

I hope this cleared the confusion rather than adding to it.