Description of problem:

Sorry for the title, I don't know how to briefly explain this...

Say the user is currently running "kernel-rt-core" while still having "kernel-core" installed in parallel.
When he updates the kernel through just using "yum update", say "kernel-core" gets an update, the latter will become the default, ending with not running the RT kernel anymore.

Reproducing this on my RHEL8 system, I can see grub2-get-kernel-settings relies on /etc/sysconfig/kernel to determine if latest should be used:
~~~
$ grep -v ^# /etc/sysconfig/kernel
UPDATEDEFAULT=yes
DEFAULTKERNEL=kernel-core
~~~

From the variable names above, I would expect the "family" of the default kernel to be selected based on DEFAULTKERNEL setting.
But nowhere this is taken into account, explaining the issue.

Version-Release number of selected component (if applicable):

grub2-tools-minimal-2.02-123.el8_6.8.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Install "kernel-rt-core" on a system running "kernel-core"

Actual results:

"kernel-rt-core" release becomes the default for next boots

Expected results:

only the latest "kernel-core" installation should be used as default

Additional info:

DEFAULTKERNEL seems deprecated and ignored with the new /usr/lib/kernel/install.d mechanism.
Still this needs to be taken into account.
If relying on this is not welcome anymore, then another mechanism has to be used to distinguish between kernel families, for example the following piece of code:
~~~
KERNEL_CURRENT=$(uname -r)

if [[ $KERNEL_VERSION == .rt && $KERNEL_CURRENT != .rt ]] || \
[[ $KERNEL_VERSION != .rt && $KERNEL_CURRENT == .rt ]]; then
...
fi
~~~

which enables to find out if the kernel being installed ($KERNEL_VERSION) is of same family as currently running one.
The weakness of this is this doesn't work for other kernel namings (here above I check on "rt" naming).