mt7615: slow tx (AP) in non-ideal conditions — problematic rate selection?

I'm having here a pair of Xiaomi routers, Mi WiFi 3G (mir3g) and Mi Router 3 Pro (mir3p) together with an Intel 9260 client in my laptop.

For the purposes of the test, I've been using 23 dBm transmit power and a 80MHz-wide channel 161 on both APs.

The immediate problem is that under near-ideal conditions (i. e. me standing a few meters away from the router) both routers show effective tx throughput in range of 50-60 MB/s (measured with iperf3 -R to a standalone server), but under non-ideal conditions (i. e. moving into another room that's separated from the router by a wall under a steep angle) the mir3g shows 30-40 MB/s (stable) while mir3p degrades to 15-20 MB/s (unstable and fluctuating).

Thing is, forcing a fixed mid-high rate (e. g. echo 386 > /sys/kernel/debug/ieee80211/phy1/rc/fixed_rate_idx for the described scenario) makes mir3p perform at least as good as mir3g.

Looking at the statistics (/sys/kernel/debug/ieee80211/phy1/netdev:wlan1/stations/<mac>/rc_stats) while a bandwidth test is in progress without forcing the rate, I'm not even sure if the driver over- or underestimates the rate as it jumps around quite wildly between VHT80/SGI/1/MCS[7-8] and VHT80/SGI/2/MCS[4-5] and sometimes VHT80/SGI/2/MCS9 (with none of these rates being the experimentally discovered optimal 386).

Could it be more of the same as in 0b6520bd1c98b57e5f0835a0fa8d6c8ca16d2191?

I can test any changes and post detailed statistics/anything else if you need.

Reproduce the AP behavior with iperf3 -R under near-ideal and wall-separated conditions, then inspect phy1/netdev:wlan1/stations//rc_stats and fixed_rate_idx. Compare dynamic selection with fixed rate index 386 and investigate the rate-selection change referenced by commit 0b6520bd1c98b57e5f0835a0fa8d6c8ca16d2191. Done means stable throughput comparable to the mir3g case in non-ideal conditions.