My question is if there is anything in your firmware that you suspect may eventually interfere with integrated closed source components?
Since I can't view the code, I have no way of knowing for sure. Could be something as simple as AiMesh checking the firmware version to determine compatibility, and since my version numbers are different from stock firmware, that alone would be enough to break things.
. Do you know if Asuswrt 49447 for AX86U is based on the same GPL as Asuswrt-Merlin 386.7 to begin with?
It's not. 386.7's RT-AX86U is based on 48966.
At least are the wireless drivers and AiMesh components the same?
Impossible to tell without having access to the source code. Even comparing binary files would be useless, since recompiles would result in slightly different binary files, as there are dynamic elements such as date stamps that will change between recompile of various elements. Linking can also potentially be slightly different, without implying code changes. Or there could be something as trivial as Asus adding a line of debugging output that would change the file without affecting it's actual working.
And the wireless driver is also only a fraction of the equation related to wifi behaviour. There are other Broadcom components that may affected it, such as the DHD driver (which loads the wireless firmware I listed in my previous post). The initialization/configuration code done by the rc daemon (that part is also closed source).
The same thing occurs in regards to the ACSD daemon. The daemon itself is closed source. And the code that configures it also is. So something such as people reporting that their 160 MHz channel more aggressively gets downgraded to 80 MHz could very well just be a configuration parameter that tells ACSD how many milliseconds of radar signaling is sufficient to force a channel downgrade (hypothetical scenario here). Wouldn't mean that acsd is broken, or even that acsd had changed.
Also, wifi "not working" does not always imply that something was broken. Let's take another hypothetical scenario here. Let's say you have a security cam that is not compatible with Airtime Fairness. Let's say you never disabled that feature because you didn't know, and your camera was connecting fine. Then at some point, Asus/Broadcom realizes that this feature is not working at all, and they fix the feature. Next driver release, your camera suddenly no longer connects. Does that mean that the new driver is broken? No. It means the new driver actually fixed something that was broken, and your 25$ Aliexpress security cam shows itself unable to work with that feature that is suddenly properly used by the router. This is why downgrading firmware to "fix the issue" is NOT proper troubleshooting. Proper troubleshooting is going through what I have been saying for years: if you have wifi issues, then disable the more esoteric/non-standard wireless settings, starting with Airtime fairness and Beamforming. Next step would be to reset your wireless settings to their defaults at both ends.
That's why "It was working in a previous version" is meaningless to me. It does not confirm that the newer driver is broken. It may actually be the complete opposite, and what's now broken is the client.
This scenario isn't as far fetched as you might think, since it actually happened before. A newer wireless driver implemented a specific error correction feature that wasn't working before. Suddenly, XBox is no longer able to maintain a stable wireless connection. So the "Optimize for xbox" setting was added to the Wireless setting. What's broken here is not the wireless driver, it's the XBox support for that feature, and the optimize toggle merely disables the setting in the wireless driver. Because Microsoft couldn't be bothered to fix their broken wireless client code. Maybe they eventually did, nobody knows.