Yes, it probably can. As you say, some subsystems might interact - the claimed benefit of doing this subsystem-by-subsystem split is that it avoids conflicts with ongoing work that will conflict with a large patch, but this is also the downside; if ongoing work changes the set of interactions between subsystems then a maintainer may find themselves unable to emit the log message they want (because one subsystem is using kernel::fmt while another is still on core::fmt).
This sounds like an abstraction problem. As a developer, i just want an API to print stuff. I don't care about what happens underneath.
Could you add an implementation of the API which uses core:fmt underneath. Get that merged. You can then convert each subsystem one by one to use the new API. Since all you are changing is the API, not the implementation, there is no compatibility issues. Then, once all users are converted to the API, you can have one patch which flips the implementation from core:fmt to kernel:fmt. It might take you three kernel cycles to get this done, but that is relatively fast for a tree wide change, which sometimes takes years.
Andrew