If those guarantees are more important to you than playing
by the rules of the Gnome Bindings set, than Gtk# may
simply be better of staying outside...

First, we have to see the problem from a high level and ask ourselves: is
Mike's goal to not break compatibility with existing Gtk# apps incompatible
with the rules of the Gnome Bindings release? In my opinion, it is not. You
can easily say the following: you are going to follow the Gnome Binding
rules, you are going to break the GTK# code to 3 sub-levels or as required
by Gnome (e.g. bindings for gtk, gnome-core and gnome-desktop, with new
library names), but for the next 12 months you are going to provide a fourth
set of libraries and headers that are fully compatible with the old GTK#
monolithic way. With these 12 months you are offering a migration path to
your existing third party developers, as this fourth "legacy" build will be
building by default (and should be configurable to not be built if a distro
doesn't want it). Yes, this will add a bit of workload initially and a bit
of Makefile magic, but at the end, I think it's important to abide to the
Gnome rules for modularity, and at the same time to cater for your existing
devs.

Now, speaking as the maintainer of www.GnomeFiles.org I tend to watch
developers and their activity like an owl. I usually notice who is active
and who is not. The point of the matter is, GTK# has only about ~50
truly-active apps today. From these 50, the 10 of them are very well done
and important for a generic Linux desktop (e.g. Banshee, F-spot,
Monodevelop... Bless & SportsTracker are some other favorites of mine).

If you are not going to provide the suggested fourth "legacy" build in
parallel to the new gnome-oriented modularized builds, and you indeed decide
to break compatbility, I suspect that 15 of these active GTK# will update
their makefiles to compile with the new set of libs/headers within a month
from your gnome-oriented release. I expect another 10-15 to do so in the
next 3 to 6 months. At the end, you might "lose" 20 applications, tops --
which is not the end of the world. And by becoming part of the Gnome
ecosystem and consequently get installed by default on more distros, will
bring you 20 new apps fast-enough anyway. In conclusion, I don't believe
Mike's rules and Gnome's rules are incompatible. But if Mike decides that
they are, he will still not lose much of the current GTK# momentum
application-wise.

Instead, what I am personally concerned is API/ABI stability *after* GTK#
becomes part of Gnome Bindings. Currently, builds of new versions of Mono
are breaking binaries compiled only 3 months ago (TomBoy is just one example
in my case). This is unacceptable IMHO for a good desktop experience. If
both Miguel and Mike can guarantee to the Gnome Project that newly compiled
gnome-gtk# apps are guaranteed to be working in the forseeable future with
newer versions of Mono and GTK#, and he abides to the Gnome Bindings rules,
personally I would be very happy to see GTK# as part of the Gnome Bindings
release.