The Wi-Fi Extender/Repeater with Bridged AP over Ethernet wiki document just got revised to keep in pace with the DSA architecture. The revision makes the configuration process much clear to follow, especially for newbies. Kudo to that. However the old version included the process to convert the wan port as use it as an additional lan port but not in the revised version. Initially I thought it could be due to some technical reason imposed by DSA because since 24.10.0-rc days, there have been a lot of Bridged AP problems associated with IPQ806x routers (R7800, XC500, EA8500, EA7500v1). For example, this bridged AP bug by @egc But after reading this thread by @Falco, it doesn't appear so. The wan-to-lan conversion in the Dumb AP configuration adds an extra lan port to the Dumb AP (33% increase in number) and may just avoid the use of another standalone Ethernet extender. I have been using this extra lan port in the Dumb AP configuration way back my DD-Wrt days and am happy that it is still alive but would also like it being added back to the document so that new users are also aware of the good option. Thanks for reading this personal rant. 
Just to add, I've started the thread you're linking to. For me adding WAN to the lan bridge works fine. I also needed the extra port 
But I'm very happy with @psherman editing the wiki as the instructions now result in a working AP again which I was struggling with before the edit.
You play nicely around slippery edges which you found actually using the previous guide version.
I removed it because it was confusing, inaccurate, and likely to cause problems. It had some references to older syntax (probably 18.06 and earlier) as well as newer DSA constructs.
In the majority of cases, there is no technical reason why the wan port cannot be added to the bridge so that it can be used as "just another lan port." In some situations, there may be a performance penalty if the port is not actually physically connected to the switch chip, but that's more of an edge case for most OpenWrt devices.
If I have some time, I'll try to add two examples of adding the wan port to the bridge -- one for swconfig and one for DSA. I'll make it clear that it is an optional configuration adjustment and I'll add the performance caveat to ensure that people understand what is happening if they happen to have a device that doesn't get the expected performance with the wan port added to the bridge.
Thanks for considering adding it back. I would recommend focusing on the DSA and leave the swconfig part out. It will just add confusion, especially for newbies. I remember I had to read the document 3 or 4 times over a few days to fully grasp the information that the document was trying to convey.
I disagree since 24.10 still uses swconfig on some targets. My plan is to instruct users to look at the current configuration to understand if they have DSA or swconfig and provide examples of each, making it clear that the configurations are not cross-compatible.
Yeah... I hope the article is better now. There was a lot wrong with it before -- many unnecessary steps, some actually incorrect, and others minor differences in syntax that were out of date.
Ok... I've made the promised edits -- adding the option of the wan port addition to the bridge.
I also made a bunch of other changes to clean up the document and improve its accuracy. Please let me know if anything is unclear and/or if I have made any typos or other mistakes.
https://openwrt.org/docs/guide-user/network/wifi/wifiextenders/bridgedap
Many thanks!
Only comment I would make is that you included comments on the WAN interface, and people following the LuCI instructions might miss those.
Maybe move the optional WAN config all the way down after the config file and LuCI instructions? There are more optional settings/extra info things there.
Just in general, there are (at least) three major hardware design principles involved:
- WAN port on the same switch as the LAN ports (and the same CPU port)
- easy to add it to the bridge
- WAN port on the same switch as the LAN ports (but using a dedicated CPU port, e.g. on ipq806x)
- possible to add to the bridge, but bridging will happen on the CPU, in software (slow), not great
- possible to move to the same CPU port, but needs closer attention
- WAN port not on the switch, but a dedicated network interface
- possible to add to the bridge, but bridging will happen on the CPU, in software (slow), not great (unless the system is very fast)
Unless you know what your system is doing (from a h/w design point of view, as well as how OpenWrt sets it up), it's better (faster) to ignore the WAN port and leave it unconnected. Only the first of these cases is trivial, the others are not that trivial if you don't want to needlessly slow down the system.