Was this leaked some time ago? see http://markmail.org/message/uro3jtoitlmq6x7t (although the language is here called "Dash", but they could have changed its name since last November which the mail apparently dates from) From the supposed internal email:

Javascript has fundamental flaws that cannot be fixed merely by evolving the language. We'll adopt a two-pronged strategy for the future of Javascript:

   - Harmony (low risk/low reward): continue working in conjunction with
   TC39 (the EcmaScript standards body) to evolve Javascript
   - Dash (high risk/high reward): Develop a new language (called Dash) that
   aims to maintain the dynamic nature of Javascript but have a better
   performance profile and be amenable to tooling for large projects. Push for
   Dash to become an open standard and be adopted by other browsers. Developers
   using Dash tooling will be able to use a cross-compiler to target Javascript
   for browsers that do not support Dash natively.

[...] Javascript has been a part of the web platform since its infancy, but the web has begun to outgrown it. The web development community has been backed into using large amounts of JS largely to work around the deficiencies in the platform. Complex web apps--the kind that Google specializes in--are struggling against the platform and working with a language that cannot be tooled and has inherent performance problems.[...] The emergence of compelling alternative platforms like iOS has meant that the web platform must compete on its merits, not just its reach. Javascript as it exists today will likely not be a viable solution long-term. Something must change.[...] The “clean break” option is extremely high risk--it will be a huge challenge to convince other browser vendors to rally around a new language--but is the only way to escape the historic problems with Javascript. Thus, its high risk is matched by the potential for a very high reward--a classic leapfrog strategy. [...] Dash is designed with three perspectives in mind:

   - Performance -- Dash is designed with performance characteristics in
   mind, so that it is possible to create VMs that do not have the performance
   problems that all EcmaScript VMs must have.
   - Developer Usability -- Dash is designed to keep the dynamic,
   easy-to-get-started, no-compile nature of Javascript that has made the web
   platform the clear winner for hobbyist developers.
   - Ability to be Tooled -- Dash is designed to be more easily tooled (e.g.
   with optional types) for large-scale projects that require
   code-comprehension features such as refactoring and finding callsites.
    Dash, however, does not require tooling to be effective--small-scale
   developers may still be satisfied with a text editor.

Dash is also designed to be securable, where that ability does not seriously conflict with the three main goals.

Dash will be designed to be consumed in a number of locations:

   - Browser VM -- Our aspiration is that Dash will ultimately be a viable
   substitute for Javascript as the native client-side language of choice
   across all browsers.

[...]

I actually ran into this a long time ago but couldn't find any comments on it anywhere (either backing it up, or debunking it as a hoax).