Hows that strategy working out for your users Chewitt ?
It could be better, but I have a thick skin for armchair pundits like yourself and prefer to focus on the still reasonable numbers of LE (and now CE) users running older releases on older hardware. I'm confident they are more positive about someone working to bring the latest Kodi releaase on a modern efficient kenel to their board/box, even if progress is woefully slow.
And pressing keys there is (close to) as visible as everything else?
Correct, but still not as obvious to kids/spouse as showing the PIN on the screen 
Can you share dmesg from one of the boxes again - I want to confirm the BT firmware is loaded so I can get the changes merged.
I've flagged it in team chat. I agree it should be hidden when entering the PIN.
CE have a more functional but rather ugly and complicated vendor kernel codebase. LE has an much cleaner (modern and better implemented) kernel codebase which also respects backwards compatibility and supports open source GPU drivers (so S912 is not an issue) but it's lacking mature media drivers. CE's issue is that Amlogic supports "current and one previous" hardware generation; meaning Amlogic kernel devs do not maintain backwards compatibility with older devices and frequently break support foor older devices when hacking new features in. CE wants (or needs) to use the latest Amlogic kernel drop which presumably drops support or makes life difficult. This is 100% why LE (and Team Kodi) are persuing a path based on Linux kernel standards that breaks the cycle, but it's not the easiest route, in part because we have to write the standards as we go.
I'm also interested to know if the blue? LED on the boxes is working .. and if hitting the power button results in a power off (or suspend) type action?
Amlogic sets lots of video stuff in u-boot that might not be handled cleanly when we start Linux; there's not much we can do about that and I don't have the u-boot sources for MeCool boards to replace it with modern u-boot. Experiments in that direction require you to have UART access to the board so we can see the early boot output from u-boot - and you need to have backups of the original firmware and know how to restore them in case things don't go to plan.
LibreELEC-AMLGX.arm-9.95.1.tar now has the correct BT firmware name (last image had right file but wrong name).
I'll have a look for the Realtek WiFi driver. If it's supported in-kernel I can add support. If it requires the out-of-tree vendor driver I'll pass because those break with each kernel version change and are a maintenance headache.
I'd describe all issues related to audio/video playback as "known" and since there is currently nobody working on the Linux kernel driver code that's at fault, there is currently no need for anyone to share logs. Until someone in the community with coding abilities (which is not me) shows up to fiddle with drivers or commercial projects fund futher activities, progress is stalled.
You'll find my image is more usable due to the ffmpeg changes (seeking mostly works). It's all far from perfect. Note the 44.1Khz audio config tip.
There are no plans for stable Amlogic releases because non-trivial Linux kernel driver work is required to move things forwards and there is basically nobody doing the work. I keep plugging away at general areas of Amlogic support to keep the codebase current with kernels etc. but I don't write driver code. Until that status quo changes, it remains super-fast and efficient standardised code that is annoying close to being usable, but ultimately deficient in the core media areas Kodi depends upon most.
Did you set the dtb name to use in uEnv.ini? - without that the box doesn't know what dtb to use.
NB: There is no path between legacy LE or CE releases and the LE10 codebase due to the different <evereything> and Python3 changes in Kodi - it's just not even remotely sensible to attempt supporting in-place upgrades. You can always backup and restore Kodi once booted.
Download LibreELEC-AMLGX.arm-9.95.1.tar to /storage/.update and reboot. I've added a possible BT firmware and two provisional IR keymaps. Please share dmesg for each box and test the keymaps thoroughly.
Rockchip more fixes by knaerzche · Pull Request #5201 · LibreELEC/LibreELEC.tv · GitHub <= it will be in nightlies once this merges
Running the "box" image from SD card is easiest, the -wetek-play2 image is the one that needs emmc wipe etc. and that is not trivial or recommended for most users. Update is simple; drop file in /storage/.update and reboot. If you track my private test images you should pay attention to file dates not the numbers.
Can you share "dmesg | paste" from the KIII pro as I'd like to see if the BT is working now. If you also have a KII pro box (S905 or S905D?) it would be good to see the dmesg log from that too. Also, if you can share pics/photo's of the two remotes it would be appreciated. I like to reflect the physical device layout in the keymap code.
The .img.gz file is for writing to SD card. The .tar file is for updating an existing (LE10, not 9.x) install. Otherwise they're the same. You might prefer the images I have here Index of /testing/ which have changes to ffmpeg that allow seeking in H264 (not perfect, but an improvement on the nightlies). In either image you need to set Kodi to "fixed" 44.1KHz "Analogue" output to get multi-channel audio without glitches in the audio. These images are still experimental..
cd /storage/.update
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-9.95.1.tar
reboot^ run those commands to update to an image which should (in theory) have the missing firmware for the WiFi card, and a revised device-tree file to enable BT support. If this works I can send the device-tree changes upstream to the Linux kernel.
For the IR keymap, either identify the keymap file or name that CE are using or record the keycodes, see Infra-Red Remotes - LibreELEC.wiki (which is not that hard). Make sure you note the button press order to match the recorded codes. Most Amlogic remotes use the NEC protocol.
Clean boot, wait 30 seconds, then run "dmesg | paste" and share the URL generated. In theory the device-tree has WiFi enabled, but I've never seen the box and have no idea what WiFi chipset is used inside. The log can help.
NB: I'm also interested to see what remote and IR keymap is used, as the current keymap named in the device-tree doesn't actually exist. If you share working IR codes I can add it.