PS:
One thing that struck me about Dynamo is how much sense it made not to have to promote 'raw' geometry to manipulate it.
Promotion can be a barrier. It has its uses but in a lot of cases, GC needs to be a lighter touch and always leave the manipulated objects editable by ABD/Mstn's tools after it is done.
1. In a one-off pass mode, the GC script would act like a VBA macro. The GC graph would function as a geometric manipulation-capable visual programming interface for writing the script/macro. In the example above, the script would run once on demand to change the door numbers to match the room numbers.
2. In automatic mode, the GC script would be run every time the room number changed. I get this is equivalent to GC's Element Sensor / ByElement mode. A more geometric exmaple would be a GC script that punched a hole in a wall that intersects a duct. Duct moves, GC gets call back, updates penetration. Wall moves, GC gets call back, updates penetration. After GC is done, Mstn calls back any associative dims to the wall/duct/penetration. Is Mstn's dependency manager up to 'revising instantly'?
3. In Functional Component mode, GC would add scripting and enhanced expressions processing support to the constraints solved Parametric Solids. Maybe the door is a Functional Cell and needs to be able to read a DGS parameter to know what parameters to use. Ideally, GC and FC should be fully integrated like Onshape's Feature Script or Catia's EKL.
4. ...
