Why is the Linux Kernel is maintained in multiple different places in a EOS install

In EOS there are two places where the Linux kernel is maintained. The first is in directory /boot, where there will be files like vmlinuz-linux, initramfs-linux.img and if configured initramfs-linux-fallback.img too.
The second is in the directory /lib/modules/kernelVer/. Here kernelVer is to be replaced by the output of the command uname -r. In the directory /lib/modules/kernelVer/ there will be a single file vmlinuz.

If the files /lib/modules/kernelVer/vmlinuz and /boot/vmlinuz-linux were to be compared then would turn out to binary identical. This can be verified by running the command and comparing the hash output for both the files. They would be identical.

$ md5sum /lib/modules/kernelVer/vmlinuz /boot/vmlinuz-linux
$ sha256sum /lib/modules/kernelVer/vmlinuz /boot/vmlinuz-linux

The same behavior is observed for LTS kernels too, only difference is the filename. For initramfs this is not the case. All initramfs files are maintained only in /boot directory.

So why is the Linux Kernel kept in two different directories? Wont it be better to simply have the Linux Kernel kept in one directory? If its presence is required in some other directory then a symbolic link can do the job. So in our case the file /boot/vmlinuz-linux can be a symbolic link to the file /lib/modules/kernelVer/vmlinuz or vice versa. Wont that work?

This is how Arch works.

You can’t use symbolic links between /boot and elsewhere because you can mount the ESP at /boot and vft/fat32 doesn’t support symlinks.

Isnt the EFI/ESP partition, which is /boot/efi in case of GRUB2 and /efi in case of systemd-boot, only supposed to be FAT32/VFAT?
/boot can be a ext4 partition or non FAT32/VFAT partition.

This is what the installer does, yes.

However, users will sometimes prefer to move the ESP to /boot and both EOS and Arch allow/support this.

So if I were to make the ESP partition to ext4 then would make a symbolic link between the linux images kept inside /bootand /lib/modules work? Will the system boot?

But in that case EOS is not longer Arch, it becomes something else entirely.

The ESP partition needs to have a vfat / fat32 filesystem. This is defined in the UEFI standard.

https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html

Section 13.3. File System Format: “The file system supported by the Extensible Firmware Interface is based on the FAT file system.”

If your goal is to have the whole of your system on a Linux file system, I guess you would need to install in Legacy/MBR mode.

Next time I feel the urge to reinstall EOS, I will make the ESP partition, i.e. /boot/efi or /efi and boot it. Let me see if the installer allows me to do so. Then I will come to know whether the system boots or not.

Aren’t those the standard EOS’ mountpoints for Grub resp. systemd-boot? So why wouldn’t the installer let you do so? And why do you think in doing so, your system won’t boot.

You can’t do this. The BIOS/firmware needs to the read the ESP partition. It cannot be ext4.

The system absolutely won’t boot that way.