Konquering the problem: Part 2

Konqueror and KHTML continue to be a bit of a contentious issue. My last post received quite a treatment.  There was a lot of good feedback and I appreciate the thoughtful comments people made.  There were some really good thoughts and there are a few things I want to cover that I previously didn't. So first things first:
Having clear goals and values is important, especially for a project as large as KDE.  They provide guidelines for appropriate functionality and development and having good goals is an important part of good software.  I build on a couple of values which lead to my thinking and reasoning in this.
This all starts with a simple question:  How does KDE improve a person's life?  And to extend that a bit further:  Why should someone choose KDE over something else?  KDE is valuable because it's being built to be comfortable.  Ease of use, customization and other features as well seem to be focused on this (somewhat amorphous) goal.
I think that konqueror needs to fit into this picture as well.  As it stands right now, compatability issues are pretty frequent.  That's the opposite of comfort, that's kind of painful.  Further, web browsers have become a core component of any desktop environment and so a poor (or even mediocre) browser is a very serious problem for KDE.  Going beyond that, I see nothing within Konqueror that provides extra value to attract people to KDE.
Konqueror's Quality
In my last post I referenced Krazy, and used it to argue that the Konqueror codebase had issues.  This was a bit of a mistake and realized too late that I should have gone straight to the source: bugzilla.  The amount of bug reports on Konqueror is somewhat astounding.  In my mind this is a pretty serious issue.

Binary Compatability
Because KHTML is in kdelibs there is a guarantee of binary compatibility until the end of the KDE 4.x series.  This is a valid point and certainly makes things more thorny.  However, I think that this can be dealt with relatively simply.
The Way Forward
I think that the current issues surrounding Konqueror and KHTML is somewhat untenable.  KDE users deserve a first class web browsing experience and that's something that can not be provided by Konqueror (and secondarily KHTML).  It's from this that I propose a way to go forward with this:
1. That KHTML stays within kdelibs but is deprecated.  Maintaining an HTML rendering engine is a monumental task and seems somewhat inappropriate for a project such as KDE to do.  This is especially the case because of the ready availability of high quality open source browser engines.
2. That Webkit be integrated fully into KDE and become the preferred method for HTML rendering within KDE.  Webkit is becoming more and more widely used.  It provides high quality rendering and is standards compliant.  Next generation web standards are already being integrated into Webkit (such as the HTML 5 video element).  I think it's important for KDE to start adopting these technologies to help ensure they remain open  and accessible.  Even better, Qt software has done a lot of the heavy lifting :).
3. That Konqueror cease to be the default KDE web browser.  Konqueor is a bit of a strange beast.  It's a web browser, file browser and a file manager.  However, I can see no clear reason why these things should be brought together.  Further, the number of bugs in Konqueror and the implications that has on its quality bring its future potential into question. I'm not suggesting killing konqueor.  Rather, simply not having it as a default.
4.  That Arora becomes the default web browser in KDE.  It turns out that there is already a Qt/Webkit based browser being made.  Work is already being done to have KDE integration and it seems to be gathering some steam.  It's worth pointing out that it is not ready right now.  However, it seems like going forward this would be a good way to have a high quality default web browser within KDE.
5.  That the above things occur by the release of KDE 4.5.  This leaves approximately one year for these goals to be accomplished.  I'm not entirely sure if this would work well as I'm not privy to all KDE development processes.  I would be happy to get feedback about this.
Let me points just a few things out with this.  I know it isn't perfect, things can take time to become perfect and this is no different.  The purpose of this is not to alienate anyone, the purpose is to improve KDE and to have it continue to attract more users and grow.  If you hack on Konqueror or KHTML you can continue to do so.
Closing Thoughts
I'm aware that this is a contentious issue however I think at least trying to get a plan of action of where to go would be a major step forward.  In this I've tried to balance a number of different concerns and hopefully it meets that goal.  I would like to hear what people think about this.
Update: To those who wanted to comment, CAPTCHA should be working now.  Sorry about that.
Update: It's worth pointing out again that this plan is not perfect and potentially far from perfect.  Putting stuff through the planet is excellent way to refine ideas and come out with good content on the end.