A partially related thought.
If there is thinking of actually restructuring code to minimize work
people have to do (anything more than what Greg proposed), it may be
a good idea perhaps to somehow further separate window creation and
drawing code. Last time I looked at -back for purposes of UIKit, it
seemed tightly dependent on -gui, and UIKit could use cross-platform
window creation code. Drawing is not important to it, as long as Core
Animation can easily (and cross platform) get an OpenGL context to
paint into. Everything is painted by Opal and Core Animation anyway,
and runloop is handled by it as well.
So if anyone more intimately familiar with -gui and -back internals
is willing to look at this, it'd be of great service for any future
UIKit implementation.
As it stands now, it may be easier to depend on both -gui and -back,
but I'm uneasy with pulling in everything just to get NSWindow and
NSOpenGLContext (or for OpenGL ES, an internal -back class
XGXSubwindow). The alternative is somewhat more appealing, but also
more work: using just Xlib, GLX/EGL and NSRunLoop.