As a long-time PHP developer (12+ years, yuck it up PHP haters) I look at this with a combination of awe and disappointment. Awe that someone would be willing to take on implementing a version of PHP that can run on the JVM much like Quercus. Disappointment because what they are doing is not PHP.
If the goal is to recreate the "let's build a better runtime" situation that exists in Ruby but in the PHP world, that is admirable. But if you really want the project to get any sort of traction, creating almost-PHP isn't the way to go.
If you can't run your existing PHP code in this thing, then what's the point?
Every PHP programmer has lamented PHP's TMA (Too Many Ampersands) design, inconsistent method naming, function parameters order, etc. But PHP is the 800 pound gorilla with 15 years of momentum. It is what it is: a DSL written in C that's good enough at web development.
But you ain't gonna teach that old PHP dog new tricks without creating an entirely new language---in this case a DSL written in Java. When you get finished redesigning PHP, it's not PHP anymore. It's not even JPHP.
BTW, there are already languages that are free of sigils, semi-colons, and braces: Python and Ruby have been there for 15 years. If you need to do web development in those languages, they provide ample tools (Django, Rails, etc.) Both Python and Ruby have been ported to the JVM.
I'm in your boat as a PHPer (11 years :)), but I like projects like this. I know you can't use your existing projects in it, but if it gains PHP some more respect from the general programming community, I'm all for it.
ECMA's a good choice, considering web developers should already be familiar with it, and (I think it's safe to say) it's a far better language than PHP.
A different language running on a different backend means making a clean break with all your old code. But anyone developing PHP has already made a decision to not make a clean break, otherwise he'd be using rails, node.js, django, clojure, catalyst, you name it.
What I'd like (and maybe I'll have to write if it doesn't already exist) is an ECMAScript-to-PHP5 compiler. Targeting the JVM is fine I suppose, but targeting mod_php5.c would mean PHP developers could dip their toes in more easily.
If the goal is to recreate the "let's build a better runtime" situation that exists in Ruby but in the PHP world, that is admirable. But if you really want the project to get any sort of traction, creating almost-PHP isn't the way to go.
If you can't run your existing PHP code in this thing, then what's the point?