That's kind of what I mean, some evidence that they've got a novel approach would be nice, because so far the answer is basically "STM doesn't work in code with unrestricted side effects", and personally, I'm pretty satisfied with the amount of due diligence that has been done on that result. Research should build on existing results, not retry the same things over and over.

I think the difference here is that there is not, in fact, unrestricted side-effects. Because the STM transaction scope is decided by the interpreter, not by the programmer, the interpreter can ensure the current STM transaction is committed immediately before any operation with side-effects, and a new transaction started immediately after. This loses some of the power of STM, certainly, but PyPy's only aiming to maintain internal consistency of interpreter data structures at this point, so this is good enough for them.

My thinking was that most research with STM for imperative codes have used the library approach. Since they will have full control over generated code and how it interacts with the STM, they may have more opportunities to optimize.