[speculation]
There is no hardware reset/change which occurs when the bootloader transfers control to whatever comes next (recovery kernel, OS kernel, etc) other than what the kernel itself will attempt to do on it's own as it begins initializing, so beyond things which are explicitly passed to the kernel from the bootloader (e.g. the kernel boot command argument list), whatever hardware state - clocking configuration, rate, or a whole slew of other device initializations - that the bootloader sets up can be regarded as an implicit set of "hardware state" parameters for the kernel which follows. (It is impossible for the kernel to reset *everything* back to a known state via a hardware reset, as this would just re-launch the bootloader)
So, the scenario described certainly seems feasible enough if the kernel code makes inappropriate assumptions about inherited state, sequences initializations differently, etc.
I was poking through TWRP's kernel log the other day, and was somewhat shocked to see a message about failure to read the mmc device's (Flash Memory!) partition table - followed immediately by an indecipherable message about a clocking change .... and then normal sorts of messages about partitions found.
Rather unnerving as that suggests something extremely fundamental for a recovery (partition layout) is being attempted initially in a sketchy fashion.
It does seem rather odd that some mismatch between the kernel's presumption of inherited hardware state would manifest itself in late boot behavior - the boot animation screen for the OS is in /system, no? Seems like if you are seeing things progress that far along the kernel probably has not failed in any dramatic way.
Anyhow - why not just put the question to the M-kernel dev in his thread, or give him the URL to this thread and ask him to comment?
[/speculation]
cheers
[ Edit ] I suppose I should have added that if you experience the problem yourself with a set of kernel mods, you might be able to come up with a hypothesis by bisecting backwards towards a reference commit that doesn't have the problem. Seems like a lot of work though, given that - for lack of Asus bootloader source code - the bootloader's behavior changes between releases are opaque.