Please forgive my ignorance of LEDE and everything with packages. While I do have an understanding of Linux, I have not been using LEDE but a few short months, and before, OpenWRT for less than a year. I do know how the packages work with respect to adding software to the router to add features above and beyond those included by default in the LEDE firmware, and have installed packages on my router (wshaper). Outside of that, I have no clue which packages supplement which features.
The best way I know to present this feature is to just explain our network environment and exactly what we are aiming to achieve.
There are two configured interfaces. One for LAN, one for Guest.
In Ethernet, LAN is bridged to vlan1 and Guest is bridged to vlan3. All 4 Ethernet ports are untagged vlan1, with the exception of two, which also has vlan3 tagged which connects to two other switches (and access points).
In Wireless, under both the 2.4 and 5.7 radios, there are two SSID's. One which is bridged to the LAN interface, and the other bridged to the Guest interface.
As things stand, traffic between wired devices and wireless stations connected to the LAN interface and wireless stations connected to the Guest interface are isolated from one another and neither are able to communicate outside their respective interface/vlan assignment, which works exactly as intended.
On the wireless Guest SSID, we desire exactly what the setting describes and enables, which is to isolate client stations and prevent client-to-client communication, except in the rare circumstances when governed by and permitted by the gateway.
If two stations are connected to the Guest SSID, they should not be able to see or talk to one another directly, regardless of what both of the station's IPv4/IPv6 address settings and subnet membership may be or whatever the communication protocol utilized may be (example, IPX/SPX or NetBeui). The only device on the network that connected stations on the Guest SSID should be able to directly communicate with is the Gateway/Router (and, technically, all wired devices that may happen to also be on vlan3).
The intention is to prevent guests with devices that are connected stations on our network from being able to communicate with the other guest stations via our network. There are several reasons for desiring this, but primary reasons are to protect guests and their connected devices from other connected guests who may potentially be bad actors from gaining unauthorized access to their devices and their data, prevent guests that are potential bad actors from depriving other guest devices the capability to utilize network resources through Denial of Service attacks, and prevent the spread of malware (computer viruses, worms, etc.) by guests with infected devices to other guests with devices potentially vulnerable by exploitation through automated transmission of data consisting of malware payload via our network, such as demonstrated by the "WannaCry" ransomware that spread from an infected host to a vulnerable host by exploiting certain Microsoft Windows products vulnerable to the "SMB1 EternalBlue" exploit.
However, client isolation is not desired for devices connected to the LAN SSID. For connected stations on this SSID, network communication shall be business as usual. These stations should be treated just like they were wired into an Ethernet port bridged to the LAN interface and shall be capable of engaging in two-way communication with all other devices also on the LAN interface without the requirement of intervention from the Gateway/Router, regardless of the method the target device may be connected to the LAN interface (Ethernet, wireless, virtual network switch, or any other means such a VPN bridge or by carrier pigeon).
I am going to go out on a limb and guess that the package(s) required to utilize this feature, as well as other wireless features, is going to be wpad and wpad-mini. But I am not 100% sure here. From my viewpoint, it looks more like this is feature of the wireless chipset that is enabled and ultimately governed by chipset drivers which is then controlled by packages wpad/wpad-mini (The end user chooses whether or not to enable feature through LEDE or SSH, which then wpad sets the stage for the chipset driver to do it's wonderful magic). It appears that the wpad/wpad-mini packages are working as expected and the option is being suppressed in LEDE and configuration option ignored by wpad because the chipset driver may not advertise the capability or the driver completely lacks the feature as one of it's options, as "Test Subject #2" router (Not a Netgear WNDR3800CH) has the isolation option present and is functional when enabled.
BUT... I'm just speculating here and rambling on!
If the wireless chipsets in this radio simply lack the capability to do client isolation, then that's just how it is and I am satisfied with that answer and we'll make the best of the situation and move on. Otherwise, if it is lack of support in the drivers, or poor implementation, I will be more than glad to do my part and lend a hand in trying to help make it work. Noted, my assistance will most likely be severely limited to testing development snapshots or beta firmwares (or whatever), unless you want to teach this old dog new tricks. I'm willing to learn.
There may be other devices in the wild with the same chipsets and radios as mine which also exhibit the feature disabled and lack of configuration option in LuCI owned and used by other loyal LEDE users who either haven't noticed the feature missing, didn't know about the feature to begin with, or did happen to notice the feature lacking and simply chalked it up as a feature unsupported by LEDE. If so, then I am sure the community would benefit from proper implementation of this feature, regardless of whether the chipset driver or the wpad package is the culprit.
Thanks again for your attention and assistance!