The Plasma team has no intention, desire or need to start "from scratch" nor engage in a massive redesign of the existing netbook or desktop shells.
One of the goals of Plasma from the start was to design a framework which would enable us to preserve work in the future. I was at the time quite disheartened that the design of kicker was so inflexible that, as good as it was, to make any sort of real changes to it would essentially require a rewrite of the whole thing. Even if it had been done piece by piece, at the end of a long development process there would have been no original code left. I went through the code and marked it up by hand to discover this. Keeping in mind that Kicker and KDesktop themselves were rewrites I was shocked, and so set out to create something that was flexible enough and free of internal assumptions so that we'd not have to "start over" again.
Fast forward to today and we have a robust framework with very few internal assumptions about what a primary user interface looks like. That's why we can use it for a desktop, for a netbook, for a tablet, for application dashboards and all the other projects people are building around it. Even as Qt has jostled about we've managed to keep Plasma bits coherent and avoided rewrites. Code that hasn't been touched in a couple of years in plugins and the shells themselves still works just as it did, and more importantly when we wish to add to that code it isn't difficult or time intensive.
Also keep in mind that Qt5 is set to be a "non-disruptive" release. It is mostly about cleaning up performance issues, focusing on QtQuick and improving the modularity of Qt. This will end up affecting binary compatibility, but source compatibility will remain largely in tact, especially for modules considered 'done' like QWidget based things. That means we are not compelled out of necessity to rewrite fundamental bits of our apps as we were with Qt4.
I expect there to be work to be done in the build system to reflect however Qt ends up being broken up into modules as well as a lot of work in managing the new QML2 and QScript work, something we've already started preparing for in Plasma. Otherwise, things shouldn't be too disruptive and I'm really looking forward to some of the performance improvements that will result from the Qt hackers really going "full steam ahead" on making Qt even more lean and mean than it is now.
One more important thing to consider is this:
This isn't going to happen tomorrow, or even this year.
Qt5 isn't scheduled until 2012. No release date has even been set. The release planning is still happening, but they've announced it this early so that we can all get involved. Qt being openly developed isn't just a story, it's a reality and Qt project management is putting their actions where their mouth has been. Bravo!
This means that a KDE Platform 5 can't happen any sooner than that. The earliest date that has been suggested thus far on the mailing list for a first KDE Platform 5 release has been January 2013, and even that may turn out to be "too quick". We'll see, but we have at least 2 more 4.x releases, and I would not be surprise at all if that turned into 3 or even 4 more.
As we cast our eyes out into the future by a couple of years, we are also keeping our minds on today and will continue working the 4.x code base. After all, it is what will become the 5.x code base. :)
I hope that puts some concerns to rest. As you can see, the KDE developers share pretty much all the same anxieties as you do about such a big release and are more than content to "just" deliver a more performant, more reliable, more featureful, more device-friendly version of our existing Platform and Workspaces. We've worked really hard to be able to say that, and will continue to work hard to take the next steps forward toward meeting those goals. :)