Have you considered factoring out a setup() method which Zorro runs right before run 0 and never again? Inside that function you could, for instance, allow set but disallow optimize. That way, in cases where the order of commands matters, the order is enforced by the language's semantics. Compare this to Zorro's current design pattern, where doing things out of order generates run time errors. In this case, the run time error came very late, Train did not complain but Test did.
Perhaps you can glance at the script above know that there is something funny about it. It was not obvious to me.
