MESH v0.7.0

MESH v0.7.0 release notes

Released 2026-10-02.

v0.7 lets a program's structure vary, and settles what a node's identity means when it does. It adds no MPRX syntax: conditional and repeated structure are two provisional reserved components, mesh-if and mesh-each, declared in the component model like any other. The contract they keep is spec §9.10, which is not provisional.

Highlights

• Node identity is a contract (§9.10). An identity is a sequence of (site, instance) steps. A site is a place in the templates, never a position in a render tree; an instance exists only at a repeated site, where it is a key the author declares, a string or a finite number. Reordering, inserting and removing siblings change no identity. A node that leaves and returns has the same identity and is a new occurrence: identity is a name, not a handle on whatever a renderer built. A handler's identity is its node's identity and its event.
• mesh-if. One or two element children are alternatives, chosen by a boolean when. Each alternative is a distinct site. It is never a node of the render tree.
• mesh-each. <mesh-each items={todos} as="todo" key={todo.id}>…</mesh-each> renders its one child per item, identified by the declared key and never by the item's index. The checker binds todo for the key and the child and requires the key to be a string, a number or any; the runtime checks every key it evaluates. A missing, invalid or duplicate key renders nothing and reports runtime-invalid-key or runtime-duplicate-key.
• Dispatch finds a repeated item by identity. A handler identifier is a hash and can't be turned back into an item, so for a program with a repeat dispatch renders from the stored program, model and snapshot and evaluates the handler in the scope it had. An identifier whose item isn't in the snapshot is runtime-unknown-handler.
• Conformance vectors for identity, examples/conformance/identity/ (C1–C10) and identity/repeat/ (C11–C22): language-neutral render-v1 trees for a renderer in any language to test its reconciliation against, with the pairing matching by position would make.

Compatibility

• A program that uses neither mesh-if nor mesh-each is unchanged: the same keys and handler identifiers, the same render trees, the same dispatch. The static-program tests and conformance trees are untouched.
• render-v1, template-v1, the manifest format and model fingerprints are unchanged. A repeated node is a node with a key; the order of its parent's children is the order of the items.
• Provisional. The spelling mesh-if and mesh-each, and the encoding of the new key steps (0x04, 0x05, and a repeat's key written s: or n: inside the hash), may change. Treat a program that uses them as using a preview.
• Reserved names. A manifest that declares a component called mesh-if or mesh-each gets these meanings.
• Rust API: mesh_analysis::Expectation has a new variant, RepeatKey; mesh_runtime::RuntimeCode has INVALID_KEY and DUPLICATE_KEY.
• Renderers that matched children by position were correct only for static programs. They must match by key (§9.10.10); the vectors show each case.

Not decided

The MPRX syntax for conditional and repeated elements and for declaring a key, nested repeats, the key encoding, hydration's transport of identity, and whether a renderer may cache a realization across an absence. See §9.10.12.