I strongly disagree that Groovy won't benefit from JSR 223. I think this idea springs from a misunderstanding of JSR 223.
A big piece of JSR 223 is a standardization and integration of Apache BSF. While JSR 223 is irrelevant if you want to write some of your application in Groovy and run like native Java code, it's very relevant if you want to use Groovy as an embedded scripting language.
I have a couple of applications where I've been planning to integrate Groovy in just this way. To add customer-specific behavior in a back-end application, I store the scripting language and the text of the script in a database which the application queries before running a process. If an entry is present, it adds a step to (or replaces an existing step in) the process workflow. This is a fairly typical use case for interpreted embedding which is traditional role of a scripting language. I could use BSF, but I like the new standard—especially that I can add new scripting engines simply by putting them in my classpath thanks to Java 6's ServiceLoader.
Because of situations like these, I think it would be a mistake to discourage people from using JSR 223. It does make sense to point out that direct Groovy is much better for many applications and give guidance on where JSR 223 is beneficial.
With respect to Java 6, you have a reasonable point. It really only needs the new javax.script interfaces and runs fine with Java 5 if you include the JSR 223 API. I think there are too many Java 5 features to get it easily building on Java 1.4.
I should point out that the JVM won't complain about incompatible classes as long as you don't load them. There's no reason you couldn't bundle in the new classes and let them go unused on older JVMs. As long as the rest of Groovy were targeted for 1.4, it would work fine ... just a thought, not a (completely) serious proposal.
I understand the desire to support J2SE 1.4, and would be happy enough if we just bundle in groovy-engine.jar with the standard distribution. In the long term, it might make sense to have a build option that bundles the engine classes into groovy.jar.