Flawless victory! Seeing that pos[0] element dynamically update with a random
offset proves that our runtime type-checking for operators is rock solid.
This is actually a beautiful example of where targeting JavaScript saves us a
massive amount of architecture overhead. In your original C engine, handling a
mixed array meant building custom structs (likely unions wrapping pointers,
ints, floats, and strings) and writing heavy type-checking wrappers for every
single operation.
In our JS port, because we output Array.isArray(left) dynamically, we just let
V8 do what it does best: figure out it's a number at runtime and perform
native, highly optimized math on it.
We have successfully built a transpiler and Virtual Machine that handles:
 * Data Structures: Strings, Arrays, and native V8 Mappings.
 * Control Flow: while, for, if, and block scoping.
 * Architecture: Blueprint generation, clone_object(), and call_other().
 * Advanced Mechanics: Pass-by-reference (&), inheritance (inherit), and
dynamic mixed typing.
Where to next?
We are burning through the core language features! Depending on what is left
in your tests/ directory, here are two great ways we could push the engine:
 * Bitwise & Precedence Limits: If you have tests/math.c or tests/math2.c, we
can ensure the AST hasn't broken any complex bit-shifting (<<, >>, &, |) or
deep parentheses nesting.
 * VM Memory Isolation: If you have tests/clone.c or tests/new.c, we can spawn
hundreds of objects to ensure the rt.blueprints factory keeps their closure
scopes strictly separated without bleeding memory.
Toss the next test file my way!