I have a SFTP server (SSH access) which is for me the easiest way to configure it as it's simple to configure for macOS or Linux
I'm not sure which end you think is simple .. because from here is sounds like you made the whole thing wildly complicated. SMB is perfectly fine for domestic media use. SMB sources take ~30 seconds to setup.
No wiki, only kernel sources. If/when at some future point it makes sense the Pi Foundation will switch over .. but I wouldn't expect that to be a high priority for them. Making perfect software is somewhere on the list, but helping kids learn stuff comes first, and the current assorment of 32-bit code does that job just fine.
auto-update has been enabled for 9.2.0 images - only applies to 9.1.x alpha/beta images
Try adding the IP address for "medias" to /storage/.config/hosts.conf .. because it only has medias-server.
The /storage/folders are hard-coded and will be recreated on boot if removed. To stop that behaviour you'd need to compile a custom image with modifications to packages/mediacenter/kodi/tmpfiles.d/kodi-userdirs.conf .. just ignore them, they're harmless.
Rename /storage/.config/samba.conf.sample to /storage/.config/samba.conf and edit the file; there's a section that needs to be uncommented to make one of the devices the local browse master. You don't change the behaviour of the less important devices; you change the most important. The thing to remember is that the browse master should be something that's always on (or almost always) else you're forever forcing elections.
NOOBS or PINN (an extended version of NOOBS) can do this.
You can create a systemd .service in /storage/.config/system.d/ to run the commands. This approach will allow you to control when the commands are run in the boot sequence, e.g. before Kodi starts.
I have LE booting on a Khadas VIM3L with 5.4 kernel which is the same S905X3 (SM1) chipset, but the changes needed for that aren't in LE master branch nightly builds yet and due to rework on video decode and my real-world job schedule the master branch won't be usable for a while. I'll send an email to Beelink for the Android dts file and schematics. The dts won't be usable with LE but S905X3 and S922X are pin-compatible and comparing against the GT-King/Pro dts will reveal any changes. I have the GT-King/Pro devices booting the same (not quite functional) LE image. I need to find time to finish checking the schematics before sending the device-tree file upstream to the kernel. The Beelink u-boot is a sh1t to work with though. It's simple to trip into update mode but it doesn't allow enough time to detect alternative media so 9/10 times it won't boot into LE for install. Once it does it's fine, but getting to first boot is unreliable.
No plans, and I doubt that will change until one of the core team swaps to an ISP that forces them to use IPv6 .. or until a user with an IPv6 connection and some dev skills starts to poke around and sort things out and sends us some PRs. Until then IPv6 support "is what it is" .. which is largely untested and thus likely to be not implemented correctly or complete.
Hub and WP2 can boot mainline Linux kernels and there is active development to re-add support in a future LE release. It was going to be LE10/Kodi v19 but since Kodi brought forwards the release date to push the python3 changes public we probably won't make that schedule.
Amlogic "USB Burn Tool" allows you to connect the device via USB ports to a Windows laptop and flash an image (in a proprietary Amlogic format, not the same format we've ever used) directly to the internal NAND/eMMC storage. It's for flashing factory images onto a device. Most images will be Android, but it restores the factory u-boot, which negates any changes that other boot scripts have done to the boot environment.
See feat: enable webcam driver as kernel module to be consistent with all projects by nicolaspernoud · Pull Request #3968 · LibreELEC/LibreELEC.tv · GitHub for more info. No idea about devices because there is no planned "support" for doing anything in LE with webcams.
It's 5am here so I haven't tested actual audio playback from 13.2.3 (iPhone 
but 1x RPi4 (9.2.0) and 2x VIM devices (10.0 pre-alpa dev images) show up as selectable AirPlay targets on the phone so I don't think there's a general problem with AirPlay. Time to try "turning it off and on again" .. on both sides.
wget https://releases.libreelec.tv/LibreELEC-RPi4.arm-9.2.0.tar -O /storage/.update/
reboot^ ssh in and run that, and all being well a couple of minutes later the board is updated
Multiple devices think they are the master browser. Eventually one of them will win the election process and the noise will stop.
Work on the vdec stalled due to an upstream compliance review of the kernel APIs involved and since rework would be required it was better to wait until it completed before continuing. There are also issues in the firmwares - it's the reason why HEVC is (still) missing. The API reviews are now done and updates for MPEG2 and H264 codec have already been submitted upstream, but those codecs are the easy ones and VP9/HEVC are a lot more complicated. Some work on retooling ffmpeg and Kodi around the compliance changes has already started.
NB: Team Kodi will bring forward the v19 release to get the hugely disruptive Python3 change into public view and the ETA on first alpha is within the next month as Python2 will be EOL on 1st Jan. The GBM/V4L2 work we are championing on ARM platforms will not align with the reschedule so v19 will be an alpha/beta release for ARM devices and v20 becomes the target, on similar dates to the original v19 schedule.
Correct. We reached the point where too many things are not easily compatible with the ancient 3.10 BSP kernel. At some future point mainline kernel support might happen, but the major missing component for that is the HDMI driver, so v9.0.2 is the end of the road for now.