Thank you for providing the AST_REFERENCE.md file! That immediately clears up
the mystery and saves us from having to grep through the compiler source.
According to your reference manual, there is no top-level global variable
mutation operator (like set or assign). Variables are strictly block-scoped
using let. Furthermore, for mutable state, the reference provides set-idx to
mutate properties on records and arrays.
This means our OS app needs to follow a standard functional closure pattern:
we initialize a state record inside a let block, and then use set-idx to
update its X and Y coordinates inside our on_event function.
Here is the structurally perfect, strictly-compliant JSON-Lisp payload. We
also use the = operator for equality, as defined in your reference.
Overwrite mock_app.json on Google Drive with this:
[
  "let", [
    ["state", ["record", ["str", "x"], 50, ["str", "y"], 250]]
  ],
  ["do",
    ["def", "render", [],
      ["dispatch", 
        ["str", "ui-render"], 
        ["array", 
          ["record", 
            ["str", "id"], ["str", "win-ast-app"],
            ["str", "title"], ["str", "Distributed AST App"],
            ["str", "x"], ["get", "state", ["str", "x"]], 
            ["str", "y"], ["get", "state", ["str", "y"]],
            ["str", "w"], 350, 
            ["str", "h"], 150,
            ["str", "z"], 50,
            ["str", "content"], ["str", "<div style='padding:15px;'>My X, Y
coordinates are managed by JSON-Lisp.<br><br>Try dragging me!</div>"]
          ]
        ],
        ["record"]
      ]
    ],
    
    ["def", "on_event", ["intent_data"],
      ["do",
        ["let", [
            ["event_type", ["get", "intent_data", 1]]
          ],
          ["if", ["=", "event_type", ["str", "window-move"]],
            ["do",
              ["set-idx", "state", ["str", "x"], ["get", "intent_data", 3]],
              ["set-idx", "state", ["str", "y"], ["get", "intent_data", 4]],
              ["render"]
            ],
            null
          ]
        ]
      ]
    ],
    
    ["render"]
  ]
]

Next Step: The Debugger
Once you verify that dragging the window correctly updates the app's internal
state and redraws it on your Android screen, we can begin building the AST
Debugger.
I recommend we start with the Memory Ingress (Microkernel Layer). Before we
write the UI for the debugger, we need to upgrade harness.js with the
sys-dump-memory dispatch interceptor. This will allow the microkernel to send
a special message to a target VM thread, forcing it to serialize and return
its active lexical environment (globalEnv) and dataStack.
Let me know if the dragging works with this new AST, and we will wire up the
memory dumping interceptor!