No, it won't be some bratty Y Combinator startup. It'll be Google (but the Facebook/Twitter integration features won't be there, mainly because they're silly).
Even when GWT matures into the world-dominating SDK Joel speaks of, I still won't use it. To paraphrase jwz: Some people, when confronted with a problem, think, "I know, I'll use Java." Now they have two problems.
Then you would want to wrap the other GWT classes. Mainly what you would be interested in is the RPC libraries so you can directly send Java data types over the wire to the server using GWTs serialization/deserialization routines. You dont know how nice it is to not have to deal with complex XML parsing until you've actually experienced it. Its heaven on earth compared to manual Ajax programming.
Oh and the debugging... I shouldn't even have to explain the merit of this to an experienced Ajax developer.
Using Rhino for this seems kinda pointless though when you could just write it directly in Java. I find it ridiculous how some hackers have such an aversion to coding Java. I think if people took the time to learn GWT they would quickly discover what kind of competitive advantage it brings when building complex web applications (web applications, not simply web pages). Yes, it is verbose, but once you get the hang of it its very intuitive.
Why cant it be some Y Combinator startup who builds what Joel describes? GWT in the hands of a small team can build web applications that compete with Googles. If you dont believe me, then I challenge you to give it a try and see for yourself. Just dont give up too quickly; the learning curve is a bit steep.
I also worked on SproutIt's Mailroom app, which is about 80% of the functionality of GMail, implemented by 2 dudes (one backend, one part-time front-end) over the course of a year (also in Ruby on Rails). Sprout's since released their toolkit, called SproutCore, but its docs are still a bit sketchy.
My $.02 -- too much of the plumbing for web 2.0 takes place on the server, which is why time to market on the server-side has been so important over the past few years. With Prototype, MooTools, YUI, etc. a lot of the fancy front-end tools can be bolted on after the fact.
Also -- how many apps fit the mold of a 100% full-screen AJAX app? Email, spreadsheet, word processing, calendar... what else? Reading news, surfing blogs (outside of an RSS reader), googling for information, etc. do not fit the mold of a 100% AJAX app.
Everything in GWT is treated as AJAX app, in that all RPC's are asynchronous. But all GWT apps dont have to be "100% full screen". You have the freedom to do whatever you want visually, including wrapping JS libraries for animation, drag drop, etc (which I've done with my current project).
That being said, I agree with your comment about not everything fits the mold of an Ajax app. Like if you are not building a web application. Rails will be faster and more immediately gratifying in most situations.
Now I DEFINITELY don't want to use GWT.
That is a bit odd, its a bit like saying you couldn't get Dojo to scale so you switched to Postgres. I assume if their startup was happy with ajax idioms in RoR, then they would be mad to build it in anything else, as it does so much for you (but if you stray too far, ouch).
In order for GWT to work for other languages it would need to be totally rewritten, unfortunately. That is unless you could somehow write an adapter for the core GWT JRE emulation library (java.lang & java.util classes). But like you say if the language your adapting to the Java code is not statically typed, you will have a hell of a time b/c the compiler is based on the assumption that the language is still java and therefore static. Like you say, you might end up having to force the programmer to follow certain conventions. Like always naming certain datatypes a unique way, so your adapter could map it back to specific static Java datatypes. But then doing this kind of defeats the purpose of using a dynamically typed language anyway..
I know its unpopular, but for GUI stuff I prefer statically typed code. It is more verbose, but I find GUI stuff really hard to test (even with friendly tools) and having the compiler do some more work for me I find saves time on silly errors when manually trying stuff out. Yes I type more (or my IDE does really), and I am doing the work for the compiler to some sense, but I find it easier then any other way I have worked for many years doing this.
Its actually ironic (in the alanis sense), I would love a good static typed GUI language, but a dynamic one on the server ;) Maybe my brain is backwards, but I haven't been convinced so far by anyone who has shown me they actually do anything with what they talk about.
I haven't written any Java code, but I recognize that my opinion was not formed by modern experiences: I was woefully unimpressed with the insanely slow craplets of the late '90s (and Paul Graham's mentions of Java in his essays didn't help improve my opinion of it either ;).