I agree with those points, and would like to add a couple more:
- Remove unused methods in DiagramEditor and DiagramComposite. There are some public methods in these classes that simply rely in DiagramBehavior's (I like the new name) equivalent, and should be called there. Currently there are 13 public methods in DiagramComposite that don't belong to an interface, and several that do but only call DiagramBehavior This would probably prompt us to move some methods from IDiagramContainer(UI) to DiagramBehavior.
- Review the relationship of the diagram with its containing part. What we are doing now is great for an editor, or a single-diagram view, but not for other configurations. We could add a method in DiagramBehavior called "hookWorkbenchPart", or something like that, that would trigger all the things we are doing with the Part right now. DiagramEditor would call it as soon as it created its DiagramBehavior, but DiagramComposite wouldn't. If somebody wanted a single-diagram view, it would have to call diagramComposite.getDiagramBehavior.hookWorkbenchPart() to hook the actions, for instance.