Console-only emacs frequent redrawing corruption in multiple terminal programs in WSL2

I'm running emacs in a console in WSL2 and frequently get redrawing corruption when running mu4e, org-agenda and when company completion pop-ups show. They are trivially fixed with a C-l but it is frustrating. I've tried Windows Terminal Preview and alacritty, but with the same results (although anecdotally, alactritty corrupts slightly less frequently, but that could be just a biased observation). [Why console mode? - when I run using a Windows10 X server I frequently get crashes when shutting/opening laptop lid, so it's more straightforward to run purely in a console than use emacs --daemon and try and reconnect, in which case occassionally the daemon wedges and/or the X-server] emac version: GNU Emacs 28.1.50 (build 2, x86_64-pc-linux-gnu, cairo version 1.16.0) of 2022-04-04 Does anyone else see this? Is it a Windows terminal problem, a WSL problem or an emacs problem? Any comments are really welcome before I dive deeper into this rabbit-hole.

Might be something related to x forwarding to wsl. Does this happen with the graphical emacs on WSL ?

No, graphical emacs works fine, the problem is only apparent when running a *windows 10* terminal with wsl inside, and emacs -nw inside that.

So, I've investigated a bit more: - running `emacs` over a X-server does *not* exhibit this behaviour, just to confirm - running `emacs -nw` inside a `rxvt` graphical terminal does *not* exhibit this problem (again, this is all with WSL2) - running `emacs -nw` inside a `tmux` session inside a Windows Terminal or Alactritty terminal (again, all with WSL2) does *not* exhibit this behaviour. Some of my emacs colours appear slightly different (e.g. marking a region does not appear as a visible region, although the mark works as expected) - running `emacs -nw` *after closing a `tmux` session* in Alacritty or Windows Terminal does *not* show the bug! My emacs colours are returned to normal. This last point is where I'm now officially baffled, and obviously this rabbit hole goes deeper :-) But may this report help some poor soul in the future

It might be possible that one of your TERM related variables change after running tmux. ​ I'd run something like this: $ set &> before.term $ tmux whatever $ set &> after.term $ diff before after

So, I think I've ~~solved~~worked-around this. My tmux comment was *not* correct, although the issues were fewer. But in the back of my head I started wondering "why do I only notice this now, what have I changed?". And the issue only shows if I start `wsl` from an existing PowerShell windows session. If I use Windows Terminal Preview and start an WSL session directly, everything displays correctly. So I'm leaving this here for the search engine gods and I think I won't explore this rabbit hole any more.

Might be worthwhile lodging a bug with the terminal devs. But thanks for coming back with a resolution for it, it'll help someone I'm sure.