Sorry, I didn’t mean to imply that hashrate on one lane is directly impacting block times on another - I am saying that the slow adjustment of the LWMA paired with the violent hashrate swings (in both directions) are resulting in overall block times exceeding the 2min target.
This is part of the problem, right now the ability to mine many blocks in quick succession is resulting in pools gaming the network to exploit small windows profitability on a particular lane, after which they usually switch off/abandon the network. You can see others observing this behavior in the hashrate concentration thread. This is causing a “hangover” effect with these hyper-fast blocks in the LWMA difficulty calculation window. Your solution somewhat remedies this by preventing these hyper-fast blocks in the first place.
I understand you initially proposed this to solve reorgs, but I believe it would indirectly solve some of this blocktime variance issue as well.
You also mentioned “tuning some of the parameters to make it adjust quicker” in your issue, which is the most appealing part of your proposal. If we could just shrink the window from 90 to 45, for example, that would be a much simpler fix compared to implementing something entirely new like DGW/MultiShield or an EMA. Maybe I misunderstood and you only meant tuning the target_time parameter and not block_window?
Also, we do see reorgs every day as far as I know. Just glancing at the network as I write this I can see a 3 block reorg from 27893-27895 with 4 blocks mined in rapid succession ~1min. It’s not a massive reorg, but it is an issue - and if bridge limits are removed like many in this community are asking for this could become significant unless confirmation requirements are raised (which has UX tradeoffs).