Username or EmailPassword
The D-Bus adoption is a perfect example. GNOME adopted D-Bus without breaking anything.
Yes, this worked because Gnome didn't have an equivalent to d-bus before d-bus came along. You can add a feature without breaking anything quite easily. In fact, KDE did the exact same thing. Some components of KDE in the 3.5 series use d-bus, and it didn't require any major changes.
What KDE is doing in version 4 is quite different. They are _replacing_ their dcop implementation with d-bus. This requires breakage. Sure, they could just add d-bus support and keep dcop as well, but now you're dragging along two IPC frameworks that you have to maintain, and expose interfaces to, and load into memory. From a development standpoint, it is far better to migrate to the new framework and drop the old one.
gnome-vfs is not perfect and will be replaced by gvfs, which is being developed. But GNOME will not depend on gvfs until it's ready; that's the main difference in strategy between the current development model of KDE and GNOME.
Since when does KDE depend on technologies that aren't ready? KDE 4 is a development version, just like the next development version of Gnome will depend on technologies that are not currently ready. They will be ready on release date.
Of course, supporting gnome-vfs and gvfs, ORBit/Bonobo and D-Bus, etc, is not a lifetime solution, which is why the old libraries will eventually become unsupported and the platform released as version 3.0.
Bingo. And this will cause breakage. So how is this different from the KDE 4 situation? The only difference is that the decision to break compatibility comes at a different point.