What SWT/RAP can't address to survive in future?

Bad thing is that I can't answer this question because I can't imagine how "widget-based" SWT/RAP style applications can "support" WPF features at all. I understand that JavaFX alternative can be built in Java (or other language), which will run within JRE and use OpenGL or use Sun's Graphics2D as display. I understand that the alternative to WPF (which is actually .NET framework rendering to DirectX) can be build in Java (or another language), which will run within JRE and use OpenGL or use Sun's Graphics2D as display :).  But I'm getting lost when think about how to transpose "universal" E4 UI to any of runtime.

Technically WPF UI is CLR code + XAML data; Silverlight UI is same (CLR + XAML + optionally DLR); JavaFX Script compiles to Java byte code...

So, to be able to run on WPF and Java and Flex as designed, e4 UI will be able to translate itself into target runtime code (CLR, Java, Flash respectively), similar to OpenLaszlo compilation of LZX/JavaScript into Flash and/or DHTML/JavaScript), or Google GWT (which compiles Java into DHTML/JavaScript). If I'm right with e4 goals, then

Questions: 

Which programming language will be used for developing UI in e4? Consider:

• We shall be able to compile this language into CLR instructions + XAML, Java bytecode, and Flash programs.
• To support target environemtns fully, this language shall be as much expressive as JavaFX Script, XAML, or Flex.
• To provide the same set of components (and to have SWT-alike custom components on all supported environments) we shall develop Basic set of reusable components (widgets) in this language. 

In this language we shall be able to script 2D graphics instructions to support ability for end-users to develop custom components (such as Nebula controls)?

There are many talks about UI scripting in E4. If these scripts are a part of UI, which are deployed to non-Java runtime (CLR or Flash), how are you going to transpose scripts for example in Groovy to .NET or Flash environments. What other limitations will be? 

If UI logic / Component, which is hosted in the webbrowser (say Flash) uses Java code heavily (from event handlers), is it supposed to call into Java over network, not allowed, or you're going to translate Java byte code into CLR/Flash and deploy it onto the client? 

If everything is just fine and you managed at least (a) for Java. Why do we need to support other runtimes? (Java is already cross-platform and run within all browsers). If you disagree, and managed (a) for CLR and Flex - which Runtime will be native to E4 UI (Flex, WPF, Java)? If there is no "preferred" UI environment for E4 and E4 runs fine everywhere, what about remaining eclipse parts? Will them run headless in JVM communicating with UIs deployed to CLR, Flex, and other clients? Other options?

In relation to natural/unnatural desktop environments I'd like to share a link to GEF3D framework, which targeted to natural desktop environment as I understand it. screenshots: http://www.fernuni-hagen.de/se/personen/pilgrim/gef3d/screenshots.html and a link to screencast on the page. Do you think it will be able to develop such desktop oriented tools in E4 and expose them to the web? Will be there any limitations? [Please note Eclipse 3.x have no limitations to develop such cross-platform apps].

It looks like we are on different ends of the road, please can you go through articles of Wikipedia with a good summary of WPF and Silverlight features: http://en.wikipedia.org/wiki/Windows_Presentation_Foundation and http://en.wikipedia.org/wiki/Microsoft_Silverlight Do you have an idea how this architecture and features can be supported from E4 UI layer?

If WPF features will be fully supported in current SWT fashion, do you think it is cool to wrap all the WPF aspects in SWT? Do you think it will be cool to spell in E4 press-release "Great achievement of Eclipse Community is tremendous efforts on wrapping WPF .NET Framework in SWT... Now 80% are wrapped, innovations are continuing"? What about other .NET frameworks? Will we think about wrapping WCF to support "native" Windows Communication Layer by ECF project? What about .NET on linux? Will we wrap WPF implementations on .NET Linux? Will we switch to .NET :-) ?