For understanding what a tool or framework is good for, it is sometimes helpful to eliminate a few potential misunderstandings, i.e. what one might think from a first glace at a description or screenshot, but what is in fact not the case. There is always room for such misunderstandings, since people come from different backgrounds and with different expectations, and since descriptions are never perfect.
So here is what Cohatoe is not:
a set of Haskell bindings to the Eclipse APIs
Cohatoe is not for manipulating a running Eclipse instance (and its UI) from Haskell code, or for 'scripting Eclipse in Haskell'. What we want to do in Haskell is the internal logic, the UI and the general layout of the application are structured by Eclipse concepts.
support for Haskell-Java language interoperability
The game is not in particular to make Haskell code talk to Java code, or vice versa. It is rather to integrate logic that is written in Haskell with Eclipse's plugin model in a way that preserves the modularity and extensibility that comes with this plugin model as it is implemented in Java. There will be some more support for transporting data structures between the Haskell side and the Java side, but the interoperability part of Cohatoe is just a generic vehicle (currently simply a list of strings), and the clients of Cohatoe on both sides (Haskell and Java) have currently to do their marshalling and unmarshalling themselves.
Much more important than the language interoperability aspect is the modularity and extensibility that is so important in the architecture of Eclipse. We want to preserve this modularity and extensibility even when we write or integrate large parts of an application in Haskell.
an approach to UI programming in Haskell
Basically the same as the first point above. The idea is to have the UIs built using Eclipse APIs. Only the logic is in Haskell.
a plugin system for Haskell
This is what hs-plugins is, and Cohatoe uses hs-plugins in order to load (possibly compile) and execute Haskell code.