yes I had noticed the typo but I thought it was in the pseudo-code only, not in your real code!

What would be interesting is to collect a whole bunch of statistics in the following way. Make a class CollectStats with an array[depth][move number][search type] of chars, and then for every PV node's moves 2...N run up to 3 out of all 4 types of searches:
(1) null-window && reduced-depth
(2) null ...

Your analysis reminds me of the difference between PVS with aspiration windows at the root (let's abbreviate this as asp-PVS) and MTD(f). There's an old post on CCC where Fabien Letouzey explains this much better than I could, but here's my own summary.

Both algorithms start a new iteration with a ...

Then perhaps "static eval" is not a good way to prune/reduce moves in the first place?

And nobody is suggesting that you "blindly play move X". If, at the start of depth N, move A is best, then B fails high and fails low on the re-search, B is the move to play. Unless C, D, ... fail high in which ...

There are two possible cases here.

If you get a fail high first, and then a fail low, I would trust the fail high. It is almost always caused by a TT entry that is a bound, left over from a deeper search. You get the fail high, come back with the research with a higher beta value, and now that TT ...