To get to the meat, here are the domains I think should be discussed individually:
* Imaging Model ===============
This module is concerned with low-level drawing primitives (2D at first, but may be extended into 3D). The associated vocabulary includes canvas, painter, graphic context ('GC'), path, pencil, etc., etc., you get the idea.
* Event / Messaging Mechanism =============================
This module provides whatever it takes for individual parts of an application to exchange messages, both, graphical as well as other. Designing this module is particularly challenging if this is to be generic as some backends are rather constraining in terms of message types that can be sent / received. This module should be able to provide a uniform view on both input events ('button click', 'pointer move'), region management ('expose', 'resize'), as well as high level widget-related ('slider dragged').
I would think an event/message template library could be much more than that if real efford was put in its design. If it would be possible to design some reactor with support for event/message sources and event/message handlers and event/message proxies, that could combine with something like a 'reverse stylesheet event proxy' (by lack of a better name), that would isolate GUI graphical design, widget events and OS dependant low level events from the main program logic. Further support for fine controll over event priorities and support for other event sources (select based, polling based etc) could make for a major improvement over existing solutions, that make you have to resort to theading in order to handle other event sources in time in some guaranteed way while running a GUI. I think that if you do your event handling right, the rest of the GUI stuff could from an API point of view be not much more than an event library enabled version of some DOM/stylesheet solution. You could end up with a simple DOM like API on top of the event API, combined with some form of bi-directional stylesheet.