The argument that you can't really use modules to handle bug-fixes is very valid. However, correctly-written code is self-contained, and bug-fixes should not extend out of the scope containing the bug.
(Ok, well, duh, yeah, if the code was correctly-written, there wouldn't BE any damn bugs. Out-of-scope effects should still be rare to non-existant, though.)
The worst area for clashes are lists. The list of directories/modules in the primary makefile, for example. arch/i386/kernel/entry.S is another culprit. But why have static lists, in the first place?
If there was some means for each module to register itself in all appropriate files, at configure time, you'd end up with MUCH smaller, simpler files, no surplus entries, and NO BLOODY REJ'S!!!
Modifying the core code is slightly tricker. What, exactly, IS the core code? The scheduler? Not according to RED, which allows you to load and unload schedulers at will. The processor code, surely! But CPU hot-swapping is all the rage. To work, this has to be outside of the "core", too.
In the end, the only conclusion you can really reach is that the module loader/unloader IS the core. The rest is all replacable, and very lkely is, in some patch or other.
If everything - absolutely everything - were defined as modules, it wouldn't matter if you were using MOSIX, SE-Linux, RT-Linux, or some combination of all three. Each affects a different element of the kernel, and therefore all should be independently pluggable, without generating side-effects.