The first issue can be solved by checking collision internally, as an option, in both cases. Either way, users will want self-defined collision, and you fall back on needing to check bounding areas of objects. I don;t see the difference, save that we don;t have an internal collision call now, which we could add to give the user engine collision checking.
The second, needs a parsing correction. If a statement reaches a condition that would evaluate false, exit, but I don;t think that the risk is worth the reward at all. If we added this, it would need to be a compiler directive that is disabled by default; and I would also point out that code may expect bar() to be called in that statement, even if the conditions are false. Short-circuiting belongs in languages where it is anticipated from the onset.
If you don't favour the AS engine with the parser, than I really don;t see the point. TO me, the entire reason for even wanting this paradigm shift, was to open the engine up to more fluidic control by the scripter. This comes at a performance hit, which is why I was happy to accept it for ZC3, a rewrite, that changed the entire ZC dynamic, moved us to modern libs, added scrolling, and essentially provided an emulation layer to play classic quests. Pretty much, Solarus in ZC style, with AS, and the ability to play most, but not all, older quests.
This is why we were going to work on 2.x, while you worked on the initial set-up for something of that scope. The discussion on AS and the discussion on a modernisation rewrite, to me, are intertwined. The average user couldn't care what script engine is under the hood: They only care that the scripters supply them with free goodies. What they want, more than anything, is to make SNES style games, and they can;t, so they beg the scripters to supply them with the 'next-best-thing'.
I think this constant debate on what scripting engine to use, is just side-stepping the real issue, of how ZC needs to evolve in the next five years, to avoid being surpassed, overshadowed, and forgotten. 2.xx is a stopgap measure, toward that type of goal, and I feel as if you are spending energy trying to hammer in a new engine when the entire thing needs to be blown up and rebuild from the ground up in the near future. I just hope I'm still alive, to see it.
I'll certainly be willing to entertain whatever you create, but I think it will be offset a version or two, no-matter what. I do like the updates we've already managed to get working, and I feel that they should be deployed, and allow users to utilise them. Give them a learning curve that isn't just a cold slap in the face, and they will be more appreciative of the entire thing, and more welcoming of controversial change, in the future.
Maybe we should use the AS engine instead of cpp, and have the ZScript parser output AS instead of ZASM. [/sarcasm]