The proposed changes for Gtk+ 3.0 have stirred up quite a bit of controversy. A lot of people are sounding off against the plethora of breaking changes that are being made for "code quality" issues and don't directly lead to new features. Those hit hardest are also Gtk+'s most important audience, the application developers that rely on the framework.
Havoc Pennington doubts the usefulness of the changes,
I'm skeptical, as many others are, of claims that "cleaning up code" or "removing deprecated stuff" are ends in themselves... sometimes code cleanup is important, because the code is still in active use, and it becomes impossible to make it correct or understand it anymore. But the deprecated GTK+ widgets aren't like that; they are just sitting there untouched and are a cosmetic problem at worst. They don't significantly affect anyone who isn't using them, that I know of.
Meanwhile Morten Welinder is worried about keeping his existing applications viable,
Producing large applications is a lot of work, so when I write a piece of (hopefully) well-designed code, I want that code to stay written. I do not want next week’s GTK+ deprecation to come along and, effectively, cause my code to bitrot. (and I really do not want to write two different pieces of code for the job: one for “old” GTK+ and one for “new” GTK+.)
These concerns are not just about version 3. The Kristian Rietveld has stated that they intend to introduce breaking changes every 3-4 years.
But with tribulations come opportunities. While the Gtk+ API may be changing as quickly as project finish, the Gtk# API has no such intentions. As Jeffrey Stedfast points out, Mono developers are isolated from this and Gtk# 2 applications should run on Gtk# 3 without any changes.