Thank you for summarizing the real problem.
I think we see a lot of “I can’t boot anymore” in the forum. The reasons can be different:
However, some may be because upgrading kernels in Manjaro is risky. The time to help them could be saved.
Thanks again, @Yochanan. 
In my case, I’m going to leave kernel-alive instead, but this is reassuring for other users, as it stops them in their tracks. (And like you implied, no need to blacklist kernel-modules-hook from the Community repo.)
This is my first iteration with kernel-alive
and this the kernel-modules-hook
So seem someone has taken the idea from the reddit etc… etc… instead to improve kernel-alive also for arch an user create another version… i don’ t know this hook before today when are mentioned in this tread… what I see is more interaction with kernel-modules-hook ( if I see PR and issues opened and closed ) than with my version ( maybe is possible I’m a bad guy and our users don’t like interact with me ) so is possible it work better of my, if anyone can confirm this I can remove from our repository kernel-alive since I don’t like multiple programs for do the same thing…
I’ll continue to use kernel-alive, and keep an eye on my modules and /boot/ directory, as well as any issues with using a live/current kernel between reboots.
This is also an example of “web search crosstalk”. I recall in the past I researched on how to deal with Arch “pulling the rug from under your feet” when you update a currently running kernel (i.e, linuxYZZ). Later, with Manjaro, I revisited that problem for a solution. The AUR package kernel-modules-hook is presented as the defacto method for Arch-based distros. (Now it is promoted to the Community repo.)
I hadn’t known about kernel-alive until much more recently; let alone its history.
I hope that kernel-alive will suffice on its own accord. I’ll let you know as time goes on.
However, I still feel the core issue is the “Arch way” of kernel updates, of which Manjaro inherits downstream. 
EDIT:
Hey, hey, hey! Don’t say that… 
…because I don’t like competition. 
The reason why not many users are affected by strange system behaviour after applying kernel updates is simple: most people use Stable branch which doesn’t receive updates as often as Unstable, where chances that one will face such issue are higher.
I always thought it’s one of a few disadvantages I need to accept in exchange for access to newer packages. Now I am in shock and awe for poor Arch users who have been dealing with this since when Arch was introduced. So that’s the cost of being able to say that “BTW” phrase… 
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.
Thread reopened as per the request of the original poster.
After everything is said, maybe we can try to repair kernel-alive because it is worth rescuing.
My first suggestion is to repair the the things that are conflicting with kernel-modules-hook. The filename .old has gotten old fast. 
Better use something that noboy else will use.
Then replace all /lib/modules/.old with /lib/modules/.kernel-alive
I found it 11 times. After that kernel-alive should only be conflicting with its hooks.
Imho Ubuntu-/Fedora-/etc-like versioning is better.
With the use of metapackages (preserving original names like linux510) pointing to the latest available version of linux510, e.g. 5.10.77. This however would mean that extra modules for every kernel version should be kept available too… Or better switch to dkms entirely (if possible). Branches also add extra maintenance… True way is hard lol
Do you use hibernation ? Then you may have used kernel-alive while absent without knowing. After an Update it seems hibernation needs to access /lib/modules/${_kernver}/vmlinuz to wake up with the right kernelimage 
see @ line 162
Go back to bed. Don’t forget to take your vitamins…
Because you are right:
It’s tried-and-true, and makes moot any hack’ish solutions.
The only “cost” is extra storage used on your OS partition. But that’s only if you don’t prune older kernels after much time in the future.
I must reiterate. With Ubuntu, Fedora, Mint, and openSUSE, the issues that affect Arch-based distros don’t exist in regards to any kernel updates; especially those with the same base version, such as 513, 514, 515, etc.
I realize it won’t change anytime soon, but why on earth Arch Linux decided to arbitrarily go this route from their inception is simply odd. There is no justification for it.
It can be possible if the extraneous file(s) (such as config file keeping track of live/old modules) was written under /etc/ instead of directly inside of /usr/lib/.
You are right. This is the best solution.
But as long as that takes, we can repair kernel-alive in the meantime
I’m no developer, but here is what kernel-alive should do, as simply as possible:
Triggered upon any kernel update (regardless of major/minor version)
– protect the directory under /usr/lib/modules/ that matches the live kernel via uname -r
Do this with any indefinite number of kernel updates between reboots
Upon reboot, double-check with uname -r and then simply delete the obsolete directory
Use a file/log under /etc/kernel-alive/ if neccessary to keep track of old directories to be pruned
The last step might not be necessary. All we’re concerned about is preventing an update from “pulling the rug from underneath our feet.”
I am a developer since 1985 When looking into the sources, it does:
After rebooting it will:
So maybe it is necessary to make sure that .old never has anything other then one filename
Maybe the right name for .old would be:
/etc/keep-alive-old-modules
If it contains the package-name, it would be save from other usage, and it would be easy to find where it comes from.
Then the files linux-module-cleanup.* need renaming too. Maybe:
kernel-keepalive-cleanup.* then there will be no furter double usage of the same hooks.
Nevertheless it should be kept conflicting to kernel-modules-hook, because it does the same thing.
What you wrote seems like a safe(r) approach in the meantime. It would be up to @Ste74 to make the changes in the next release. It would also more closely honor the “don’t play around in /usr/lib/” concern.
That’s too vague. 
It should be something like,
/etc/keep-alive-old-modules-per-andreas85-suggestion-as-to-avoid-future-conflicts
Suggestion for the
kernel-alive-post.script
#!/bin/bash
msg() {
ALL_OFF="\\e[1;0m"
BOLD="\\e[1;1m"
GREEN="${BOLD}\\e[1;32m"
local mesg=$1; shift
printf "${GREEN}==>${ALL_OFF}${BOLD} ${mesg}${ALL_OFF}" "$@" >&2
}
#post transaction : check if still present old kernel if yes warning the user and do nothing
if [ ! -e /lib/modules/.old ]; then
KVER=$(uname -r)
if test -e "/lib/modules/backup/${KVER}"; then
rsync -AHXal --ignore-existing "/lib/modules/backup/${KVER}" /lib/modules/
touch /lib/modules/.old && echo "${KVER}" > /lib/modules/.old
fi
#cd /lib/modules
#oldkern=$(ls backup)
#touch .old && echo "$oldkern" > .old
rm -rf /lib/modules/backup
#Inform user
echo
msg "Warning:
-> Kernel has been updated. Modules of the current kernel
-> have been backed up so you can continue to use your
-> computer. However, the new kernel will only work
-> at next boot.
"
else
echo
msg "Warning:
-> This computer hasn't been restarted for a while.
-> You are running an old kernel. In order to use a
-> new version of the kernel, please restart your
-> computer as soon as possible.
"
fi
Only
if test -e "/lib/modules/backup/${KVER}"; then
rsync -AHXal --ignore-existing "/lib/modules/backup/${KVER}" /lib/modules/
cd /lib/modules
touch .old && echo "${KVER}" > .old
fi
#cd /lib/modules
#oldkern=$(ls backup)
#touch .old && echo "$oldkern" > .old
No I don’t use it much and that point of yours is a good one. Suspend to RAM is what I use in general, but most time my laptop is just on and running – not too much power thanks to U Intel processor.