I think there is nothing at all wrong with having a tree that's close to the syntax and then building another tree that represents what is to be done at execution, nor is there anything wrong with keeping around the syntax tree and having the execution tree look into it (through a well-defined API, of course).

You are writing a compiler/interpreter pair, like Java itself. The compiler both has a data structure close to Java syntax, and generates a data structure rather far from Java syntax (byte code). But in addition to byte code, however, various bits of the compiler's model are kept around at runtime, symbol tables and the like, to provide information needed at runtime. If it weren't for the perceived need for a separable class file, it would be quite plausible for Java execution to use the compiler's data structures directly.

Interesting, Norm talks about models; John replies by talking about trees. Does either model happen to be a tree?

That's an interesting question. The "top" of the model is the p:pipeline step and it contains an ordered list of children. Some of those children also contained an ordered list of their own children, etc. So I guess they are tree like in that sense.

There are also connections that cross tree boundaries, but if I squint I can think of those as not unlike ID/IDREF links, so I'm not sure that makes the model un-tree-like.

But neither is intentionally a model of a tree.