GLib 3? What conceivable changes to GLib are outstanding that would merit API/ABI breakage?
I just wanted to mention here again the alternate GTK+ 3.0 plan:
1) Integrate a canvas. Here's an example of real world program almost certainly on your desktop that needs it:
http://blogs.gnome.org/dcbw/2008/06/11/great-taste-less-filling/That mockup really needs a canvas that has features like painless GtkWidget embedding, powerful
styling and layout.
We could take the approach of having app authors pick one on their own (I know I would suggest hippo-canvas to Dan just because Owen's been doing such good work on it), but it certainly would be a lot better if the canvas was being driven forward the GTK+ core team.
2) Finish GObject introspection - People continue to write code in C, bindings authors continue to fall farther behind.
One possible approach with the canvas would be to have parts of GTK+ that are not API/ABI stable - perhaps they require a Havoc-style
"#define GTK_I_WANT_A_CANVAS 1". Once the canvas is stable we declare it GTK+ 3.0 from a marketing point of view (but don't change the soname), like what GNOME is doing with GNOME 3.