I haven’t written one so it’s worth explaining the status of Conductor 2:

• Entirely rewrote the current v44 script using an “enhanced” version of Conductor 1 syntax to explore a realistic way to describe and use the new routes concept.
• Considered whether it’s worth pursuing the Groovy DSL vs extending the Conductor 1 DSL…
• The decision is that the former Conductor 2 Groovy DSL is obsolete. It was premature. Part of the issue was that it was getting entrenched in bridging the functionality and implementation (at the same time) with the former Conductor 1 engine. That is not the proper way to prototype.
• Instead, modularized the Conductor 1 source code to move the engine/DSL into a sub-project.
• And added a mock Conductor Groovy DSL rewritten from scratch, focusing on how the syntax would work rather than the actual implementation. There are unit tests but they only validate that the DSL can actually encode what it’s supposed to.
• The goal is to later also do a mock Kotlin DSL and compare.
• I still need to create a fat jar where this is invoked as Jython add-on from JMRI, to ensure there’s no library mismatch for example when running Groovy or Kotlin runtime code.
• That led me to explore the fundamental issue with the current route system, namely that we must have “managers”, “active routes”, and the sequence/shuttle manager should deal with a node graph instead of a “block list”. After much back-and-forth debate, I think I finally have a system I can endorse. Now I must encode it using the Groovy DSL.