On first reading, I couldn't see any problems mentioned that couldn't be addressed with a Factory pattern. Android game /graphics devs could band together and maintain a framework. iPhone devs would have licensing issues with such a project.
Stop spreading FUD. iPhone devs would not have licensing issues. How about I point you to a number of frameworks that iPhone developers ship with today and have been shipping with since near day one.
They're all C++ or Objective-C. It's one of the insidious points of 3.3.1 that you can't used alternative languages (and it's questionable whether you could even use grammars or other code generators), but pure Obj-C or C++ libraries are all okay as long as they're statically linked.
There's actually plenty of precedent for scripting/interpreted languages being perfectly acceptable. Many emulators have been approved, as have games using Torque and Unity. And it's certain that plenty of games on the App Store are using Lua.
I thought the clause in question was for iPhone SDK 4 apps. Since v4 isn't shipping yet, it doesn't apply to any of the apps in the store now.
As for the question of interpreters, I though for the current generation of apps, the issue was with 3rd party interpreters that allow the interpretation of arbitrary code. Code that is embedded in the app at approval time isn't an issue. Isn't this why frotz can only run games that are bundled with the interpreter when it is distributed through the store.
I think that's the distinction that a lot of people miss (your post included). These are frameworks that work with apple's official dev environment, so if apple introduces a new feature, and if oolong or cocos2d or whatever is dragging their feet in incorporating it, a developer could just call directly into the SDK for it, no hoops to jump thru. Whereas if they were using Flash or Unity or something they'd have to wait for the middleware to support it.
Not that I approve of apple's stance on "original language" but I understand where they're coming from,
