A better analogy would be *writing the entirety of a programming language and a compiler* every time I want to start a new project. By hand. And then debugging the underlying compiler and programming language before I even begin writing applications. And worse, the rest of my software is still all written in machine code.

Then, I've got to write tools for my new language in machine code. I've got to write authoring software. Debuggers. I've got to teach new people on the project my fancy new language. I've got to come up with style conventions. I have to handle corner cases.

Luckily, with high level programming languages, somebody already did that stuff for me decades ago.

Not so for these hand-rolled meta languages.

Perhaps state machine mechanics, decision trees, etc., should be provided as optional tools, rather than as a framework - er - into which - you must plug.

My team once implemented co-routines (that is, the ability to "Yield" and have processing resume from the same spot next frame- so as to wait, in the middle of a logical flow - for a condition to be met) because we were sure it would make behaviors easier to write. It didn't really. A stone-age switch-statement state-machine was just as clear, and effectively as simple to use.

Although I have to admit, I have occasionally daydreamed about a graphical state machine tool.