The extensible-effects package seems very interesting. I would really like to have instances of all usual monads: Reader, Writer, State.Lazy and so on in the package. Maybe that's a project for the future :)
There is already a Reader and Writer, in Control.Eff.State. I guess Ben Foppa collected them there because they all deal with aspects of State (unlike say, non-determinism or coroutine). I must stress that thinking of extensible-effects effects as just another implementation of MTL is not productive. Not all effects can be decomposed into State, Reader, etc. layers. Manly, effects should not be decomposed into layers. The recently discussed Logger was an excellent example. The original poster wondered if Logger is a Writer, or a Reader + IO, or something else. I'd suggest that the answer is that a Logger does a logging effect. One may then think what sort of interaction with the external world executing this logging effect should cause. The original poster thought exactly in these terms and outlined three scenarios. With extensible effects, one implements these scenarios directly. It seems MTL wrought quite a round-about way of thinking about effects. First we specify the desired interactions with the world and then we start thinking of decomposing them into `usual monads'. Why not to implement the specification directly, without any decomposition? To make an analogy, it is believed that a mathematical proof can be traced back to ZFC axioms. Yet no mathematician (unless working specifically on foundations) actually thinks of ZFC when doing the proof. [The analogy is imperfect: there are effects that cannot in principle be represented as composition of monad transformer layers.]