Rearchitect the TreeView from Controls 1 and move to Controls 2

There is real need to reimlement TreeView component as there are many bugs with indexes, bad rendering and so on. As well there is insufficient functionality and interface e.g. https://bugreports.qt.io/browse/QTBUG-56230
Developers have to really struggle if there is a need to access from itemDelegate to rowDelegate and vise versa.
At the moment TreeView is in Controls 1.5. How can it be proposed for reengineering and release in Controls 2 in 5.8? For some developers (even who does not report this here) listed limitations are critical, and it might be relevant to remake it in Controls 2 in Qt 5.8.

I provide a quote from srutledg from topic https://bugreports.qt.io/browse/QTBUG-46488
"There's a need to rearchitect how models and views work too. But we haven't gotten around to it yet. One idea was that ListView etc. are too monolithic and need to be broken up; so if we break it up in the right way, we will have more reusable pieces for building similar kinds of views. Another thing I don't like is how QtQuick uses model roles whereas widget views don't, so you can't easily reuse models for both purposes... but how to fix that without breaking any existing implementation anywhere?
Should the proposed tree in Controls 2 actually still be based on ListView? If not, then it's more work, but also more opportunity.
I bet we could make a really efficient one that populates scenegraph nodes directly instead of being composed of hundreds or thousands of Items... but there are tradeoffs between compactness and styleability. I'd like to try some day though.
If you are writing a conventional desktop application, you can use widgets; QtQuick is not necessary unless you need a "fluid" UI like what is typically found on a mobile device. A tree view has some usability problems there anyway.
But we know that we need a better tree for QtQuick eventually."