The issues the patchset is fixing came up in the wild with an app doing single step tracing through SEH handler. That requires unwinding from any instructions encountered in the called functions, even those where we are normally very unlikely to get unwind from, like instructions between popping frame registers and returning from the function. The problem occurs when stepping through Wine's functions in ucrtbase, kernelbase, ntdll etc. Whether the problem is actually reproduced or not depends on compiler behaviour (different gcc versions seem to behave differently).
There are two main problems encountered and fixed: 1. Now any unwind from the instruction between popping frame registers and return is going to be broken: frame register is used after being popped (and thus having some unrelated value). Judging by our existing tests that is also a problem on Windows before Win10, but I guess even on Windows 10 it might be a relatively rare problem to encounter while tracing instructions this way because likely functions rarely have frame register on x64, while gcc, especially certain versions of it, seems to like rbp based frames a lot.
2. Tail call handling. Looks like existing jump opcode handling is sort of reversed (Windows treats jumps out of function the same as 'ret' which is probably the only way to handle tail jumps correctly). Besides there is 0xff/4 jump opcodes we don't not handle at all currently (those seem to not try to mind the jump address at all on Windows treating that same way as 'ret', while for indirect jumps it doesn't look possible to mind in general).