I have no idea what the reboot issue is but I rather doubt it's related to hardware revision as while there are tweaks/differences over time, they're rather minor changes.
For subs I'm watching this mesa issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12702
I don't see anything 'wrong' in the log, so first thing I'd do is update to the latest LE13 nightly image from https://test.libreelec.tv to see if the newer kernel/firmware used magically fixes the issue?
If I grab a modern pci-e card is it likely to just work?
As a general rule PCI cards are better supported in the upstream kernel because there are fewer chipsets and support for new chip families often starts with the PCI variant as this easier to author/upstream code for. However the real answer is 
as support depends entirely on the chip on the card, and most vendors have the habit of shipping v1/v2/v3 versions of a card with the chipset changing between versions; hence why we usually abstain from recommending WiFi hardware.
The =y option means the module is compiled into the kernel and always loaded (whether it's used or not) and =m (which is more appropriate in this case) means it's compiled as a loadable module and only loaded if matching hardware is probed.
I'll send an update to include the module in the Generic image kernel config.
The dmesg log shows no mention of a USB WiFi device, but it shows there are USB devices being endlessly reset. An educated guess is that too many USB devices are attached to the same internal hub and it cannot supply enough current for all the devices to power up and work properly (modern or cheap WiFi dongles can require a lot of current). An alternative guess is that it has some kind of issue with the USB 3.0 port speed.
I'd start with removing all other USB devices and see if that helps things to run stable? - If not, see if you can disable USB 3.0 and force the hardware to USB 2.0 in the BIOS/firmware config or perhaps use a USB 2.0 extension cable to force the USB connection down to USB 2.0 speeds.
In short, the device doesn't show up on the bus correctly so we can't even see what chipset is inside to understand whether drivers are in the LE image. You did say lsusb lists the device, but on a functional level that doesn't actually mean much.
video=HDMI-A-1:1920x1080M@60Add that ^ to boot params in extlinux.conf on the SD card. It will force initial DRM output to 1080p/60Hz. Any better?
The 4c-plus was added after the release of LE12 so until LE13 ships there are only nightlies.
No idea as I don't track Rockchip development. I've moved the thread. The Airplay/CEC interaction makes no sense to me and sounds more like an inadequate PSU issue than an actual bug in code.
The latest version should have the greatest number of fixes/updates, but these are nightlies and we are crowdtesting changes so we avoid calling anything 'stable' because we occasionally break things.
What chipset is in the Wavlink? .. share the URL from "dmesg | paste"
palle_c add "ssh" to boot params in syslinux.cfg and the SSH daemon is forced to start on boot.
Connector 1 (42) HDMI-A-2 (connected)Move the connection to HDMI-A-1 which is the connector nearest the PSU socket.
Remove drm.edid_firmware=HDMI-A-2:edid/edid-HDMI-A-2.bin video=HDMI-A-2:D from cmdline.txt
Add video=HDMI-A-1:1920x1080M@60 to cmdline.txt
Ensure RPi firmware is updated (done from LE settings, Update).
If using an Argon case, remove the board and connect direct without the problematic internal connectors.
Reboot. Fixed?
If not, remove the SD card and allow the RPi to boot to a display test screen. Anything flagged?
HDMI-CEC control for the win 
I see nothing in the log beyond the wlan0 interface being created. There's no connection attempt.
I also see no reason to generate a Kodi debug log (as requested). It won't show anything related to connman/iwd/rtw89.
Urgh.. thread merge doesn't work nicely (sorry) but we'd prefer to continue with a single thread on the same topic.
Thanks for confirming. I'll work up enthusiasm to push an update to LE12 to enable that kernel module. I'll avoid the tempatation to bump the kernel as I haven't tested/booted LE12 for some time now.
In attempting the long list of Qs:
* I've not seen reboot issues for a while, although I use an eMMC module for testing not SD cards. I'll add a card check to a to-do list of things, but I caution that I'm often rather slow at ticking items off the list.
* Known issue with subtitles. I'm told it's a problem with lima/Utgard and needs something fixing in mesa, which is taking time.
* No idea but probably a Kodi issue not a LibreELEC issue.
* System Info page clearly shows K22 and the build details (bottom of the page) using the default Estuary skin.
* No idea about NTP issues, I've never needed to change the defaults.
* LE settings changes the OS keyboard (console etc.) not the Kodi UI keyboard in Settings > Regional > Virtual Keyboard Layouts.
* If you want name resolution to work without DNS, configure /storage/.config/hosts.conf as you would /etc/hosts.
* Yes, putting .tar or .img.gz in /storage/.update will work.
* The .img is a standard USB/SD card image. Most Windows tools don't understand Linux partitioning schemes well so I'd guess VCD is just another one to add to th elist.
Is there anyone out there using LibreELEC on a Zero 2W?
Stats show 33 active installs on a Zero 2W board. 1x on 12.0.2, 1x on 11.0.6, 24x on 10.0.4, and the rest on old nightlies. Installs do not prove it's viable, I'd expect half/most of them are just using LE to run something like Tvheadend in the background. Playback will not be great and there's no cure for that. If you're still keen to have a poor experience, the instructions are probably in this thread.
