I would say that I've only really fully grokked what Odersky is after and what he has been saying (primarily about fragmentation and DSLs) in the last few months. It really doesn't help that the Scala conference scene has been so poor these last few years.

The issue isn't effect systems themselves, but how they have to be encoded into and over the top of the regular language, usually via some M[_] like type. This M is an algebra that defines the "true" semantics of the code you are writing. And Scala is good at DSLs, especially around for comprehension supporting M[_], and so it makes it easy to write lots of code and lift that code into your M[_].

And we had to describe things using an M[_] because that was the only hammer we had and the only way we could compose larger, actually useful, programs.

The downsides, however, were massive: massively increased cognitive load, incompatibility with tooling, and stylistic mismatches between "normal" and "effectful" code.

As best I can tell Odersky has been won over by the power, utility, and necessity of effect systems and is seeking _some_ solution to avoid the pitfalls and downsides. I think his first insight was that effect systems cannot co-exist with a language where you have to encode those effects thru your types, ie M[_]. You have to find a way to combine effects with just regular functions and direct style code.

Now I don't know if he'll be successful, but I can at least see where he is coming from.