Topics discussed:

• A prototype test runner that reads the JSON test definitions and evaluates them directly was shown working — as versatile as the current setup, where the tests live in JavaScript. The counter was that the authoring experience gets about twice as bad, so the advice was to finish covering the features first and switch afterwards rather than let the migration eat the schedule. One thing the move fixes: when you generate JSON from JavaScript you cannot control number formatting, so a value that should be a double is written out as 1 — JavaScript doesn't separate integers from doubles — and that stays untestable until the JSON is the input rather than the output.
• Column ordering was resolved without constraining anything: view runners can output what they like, but if the output format has column ordering semantics, use the ordering the spec defines. Row order stays undefined.
• The feature voting page has arguably done its job — its results confirm there's no gap between what's in the spec and what people thought the first version should contain. The suggestion was to retire it in favour of the test matrix, which shows coverage feature by feature, so there aren't two artefacts to confuse people. The more pressing ask was blunter: get the reference implementation's build green, so that breaking something actually shows up.
• The plan for the spec site is to delete first and regrow: out go the guidance section, the tech matrix and the miscellanea page — early exploratory content that hasn't been maintained — with anything valuable moving to a separate implementation guide, and git history keeping the rest. What's left splits in two: background (home, purpose, the layers diagram) and the normative part (ViewDefinition and the processing model, with artefacts alongside). SDC was cited as having roughly the structure wanted, including its role orientation — form manager, form filler — which here would mean a view definition engine role and a validator role.
• Multiple resource types per ViewDefinition was reopened. The use cases are FHIR to OMOP, where several resource types feed one table, and normalising addresses out of Patient and Organization into a common table. You can split it into two ViewDefinitions and UNION them at the database layer, but it's logically one unit and the split loses that. From the implementation side it doesn't look hard — the JavaScript reference implementation already supports it, and the tests sometimes carry mixed resource types and filter by resource — so the real cost being weighed is spec complexity.