The usual rememdy for CEC issues that make no sense is:
a) Unplug everything
b) Turn everything off
c) Go make tea/coffee .. something that takes 10 mins
d) Reconnect everything
e) Turn it all back on again
It too makes no sense, but has a surprising success rate 
Are you running the Plex server on the same machine?
Nope. Plex on a Synology NAS.
I've been using the dontpanickodi version for ages .. works great.
LE boots from two files: KERNEL (the kernel) and SYSTEM (userspace) .. the latter is expanded on boot to create a virtual (read-only) fileystem. If you look at the SD card directly you'll only see the two files (and some other RPi boot stuff). You can unsquash or mount the SYSTEM file, but it will be easiest to just boot the RPi5 normally and do things from inside LE, e.g. from a booted device you can do "cp -R /usr/share/kodi/addons/skin.estuary /storage/.kodi/addons/skin.custom" to clone skin files, then edit on /storage. Once you have cloned/renamed/selected the custom skin you can use kodi-send --action="ReloadSkin()" to live-test changes.
You only get to that file with root privileges. If you need top-level security, you have to learn a lot.
Unless you access /storage/.kodi/userdata through the default enabled \\LIBREELEC\Config samba share with known user/pass credential (libreelec/libreelec). You can change the Samba credential in the GUI. You can disable the Samba server in the GUI. You can disable SSH passwords (or SSH entirely) in the GUI. So the defaults are (intentionally) a little open, but if that concerns you it's simple to lock things down. That will likely inconvenience you though. Catch22.
e2label /dev/sda1 "LABEL"Use e2label to set disk labels and the drive should be auto-mounted to /var/media/LABEL instead of the default behaviour of mounting to a path that includes the current /dev/device which depends on USB probe order (which cannot be controlled).
The latest https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.0.tar contains another attempt at getting HiFi-Shield devices working. There's one dtb for the original/plus versions, and one for the v2 card. The dtb files are obviously named and can be seen in /usr/share/bootloader/amlogic .. You need to "mount -o remount,rw /flash" first and copy the dtb to the card, then edit the /flash/extlinux/extlinux.conf file to use the different dtb name. I believe the S/PDIF output should work. I'm not sure if the RCA/Phono outputs will work. Let me know.
Read my first post again
Nothing inside Kodi should be fiddling with content in cmdline.txt, but perhaps you’ve done manual changes.
LE uses the same RPi kernel as RPiOS but it’s possible that one or the other is using vendor binaries not in-kernel drivers for the wireless chipset. The other probable difference is that we use iwd and RPiOS is probably still using wpa_supplicant.
I think that’s the issue. The container only sees the limited bits of filesystem you expose to it, so doesn’t have permission to walk the filesystem from the symlink to the original file.
RPi4 or (better) RPi5 are great devices for LE and our go-to recommendation.
You probably need to map the folder the app inside the container expects to find the file under, to the folder on the host that the file actually resides in, using appropriate permissions.
Different locales/charactersets?
e.g. cmdline.txt and сmdline.txt appear identical but the second starts with the Russian letter 's' (looks like English c)
RPi5 will automatically boot when power is applied (cannot be changed to do otherwise) so the remaining challenges (in rough order of priority) will be:
a) Ensuring uses don't shut-down the device. This is easily done with a skin hack to Home.xml, although LE makes that a little more complicated vs. a conventional distro as the default skin files are inside the read-only SYSTEM file. You need to clone the Estuary skin files to /storage/.kodi/add-ons/skin.custom and rename the skin add-on.xml (to avoid name-clash with the embedded one) before editing Home.xml to hide the button.
b) Ensuring the configuration remains consistent. This can be done with an /storage/autostart.sh script which runs early in the boot process to remove the existing /storage/.kodi and replace with a known-good copy: e.g. setup the device, stop Kodi, then clone files from /storage/.kodi to /storage/.kodi-good and then restore /storage/.kodi-good to /storage/.kodi in the script.
c) Ensuring the device always boots to a working LE install. This is mostly about avoiding SD card corruption from uninstended power off events (more about power-cord pulls than unwanted GUI shutdowns). Booting from USB or an NVME drive (needs an NVME HAT) are generally considered to be more reliable than SD.
I'd probably do A only unless I really saw issues that needed B or C.
The difference is Xorg vs GBM graphics; there are no differences in the Generic/Generic-Legacy kernels so while Xorg might work better on some older hardware the sole (intended) purpose of the legacy image is supporting nvidia (which cannot run GBM).
RPi5 is designed to power-on when power is applied. The RP1 chip might evolve programmable power-button behaviour over time (there were pre-launch rumours in that direction) but I haven't see it mentioned anywhere since. On RPi4 boards I've seen small circuits combined with the gpio-poweroff overlay to detect a switch state (on/off) and if left in the off position the board boots when power is applied (as that can't be stopped) but gpio-poweroff triggers shutdown almost immediately once firmware loads and applies the overlay.
but sometimes low-tech solutions are best: https://www.amazon.com/Raspberry-Supp…d/dp/B097P2NLVH
Have you set the Wireless Regulatory Domain? .. this can help with ensuring country-specific radio properties are aligned with the router capabilities.