I'm going to look at http://www.vbrichclient.com/#/en/Demos/GUI/ and reply more fully when I have done so.

But at this stage my thoughts are:

If you are telling me that to convert my applications (with many forms and some third party OCXs) I am going to have to spend a long time rewriting them for VB7 then it isn't likely to happen. Microsoft suggested the same 10 years ago with VB.Net.

If you are telling me I have to keep VB6 and keep my source code in VB6 that is just what I will do. I certainly won't keep one version in VB6 and another version in VB7. That would mean I would have to do every modification twice, once in VB6 and again in VB7. Don't forget that maintaining legacy applications doesn't mean just keeping them running. It means modifying and enhancing them, adding in the latest features (including nose-touch support if that's what the user wants) and giving them the look and feel of modern applications.

I don't really see what you are offering that I can't do now using NSBasic AppStudio. With this you code using VB source code and it converts this to JavaScript. The approach seems to be similar to what you are advocating. You create forms and place controls on them (in a VB6 like IDE), then cut and paste VB code from VB forms into them. It has the usual controls, such as a TextBox (enhanced to let you specify if the input is numerical, text, dates, etc). You do modifications and enhancements in VB, it isn't a one-time convert and you don't need to know JavaScript. It doesn't support OCXs either. It targets iPad, iPhone and Android.

My concern is you are making the same mistake that Microsoft did with Vb.Net. Deciding that language 'improvements' justify breaking upward compatibility. It didn't work for Microsoft. RealBasic put themselves forward as a VB6 replacement, PowerBasic tried the same. But again they weren't compatible. So we still use a 15 year old product - VB6.
We aren't short of Basic languages, there are dozens to choose from. I want VB7 to be one we can use, not just another on the long list of incompatible languages.
I believe that without offering a truly compatible (it doesn't need to be identical, you can use a migration tool & convert to your inbuilt widgets) upgrade so that existing VB6 source code (including forms, OCXs, DAO, ADO, calls to the Windows API, and so on) can be compiled on VB7 (for at least 32 bit Windows) you will lose the bulk of VB6 developers.
I note you suggest a VB7 Win only fork using the C++ compiler to support OCXs. This may be the way forward. But I wouldn't have any real interest in VB7 until this was available.

You ask if I would experiment with VB7.
Yes of course I would.
And after a day or so I would put it to one side, just like I did with VB.Net, with RealBasic, with Jabaco, with Basic for QT, with Gambas and the rest.

If it ain't upward compatible it ain't VB.