By checking I mean something quite rock-solid, i. e., trying to analyse loader's configuration or available kernel files and matching to uname's output clearly isn't an option.
In the general case, no, it's not possible, because nothing of the previous state can be trusted, and cannot be distinguished from a regular reboot.
Just say for a example you have a system that does NOT wipe RAM at boot (memory wipe on boot is required by some secure boot specs etc); The initial boot process and every normal reboot will generally happen at the same offsets, and wipe over everything from the previous boot over time. The kernel itself will almost always be loaded at the same address.
Now consider kexec instead of a normal reboot, and realize that everything should wind up at the same offsets, and be mostly indistinguishable.
Are there special cases where kexec CAN be detected? YES!
- Kdump explicitly loads the new kernel at a different address, and hopes to preserve the previous kernel's memory for capture of error state.
- If BIOS and kernel initialize hardware differently it (obviously) might be noted since there would be changes on each boot with switch "usual/kexec".
- As a specific example of this, the EFI frame buffer is definitely altered by the kernel during boot, and never returns to the original state on kexec.
- The corollary of this, is that if you don't control the boot of the kexec'd kernel, and it touches the hardware, there is pretty much no way to later decide if it was a real boot or a kexec boot.
As a demo, I booted a VM with a kernel, captured dmesg, then immediately did a hard kexec on it, captured dmesg again. Here's the diff between the two runs of dmesg: https://gist.github.com/robbat2/7609be2715591eac8ace3f46e852c549
I just found the answer in code, and I'd like to share.
To check what was the bootloader used to load the running kernel, check:
One need then to shift-right 4 bits to get the bootloader_type, which is described in the following file for x86 (in the kernel tree): Documentation/x86/boot.rst 
The kexec loader would show 0xD after the shift (from kexec-tools code, we can see it defined as #define LOADER_TYPE_KEXEC 0x0D).
It's a x86-only trick, unfortunately!!! Hope it helps.