Topics discussed:

• The framing that did the most work: read a ViewDefinition as functions. Every node is one function — select, column, forEach, forEachOrNull, unionAll — and the convenient shorthands are sugar that rewrites into that normal form. A forEach with columns hanging off it is really a forEach containing a select containing columns. Rewrite first, then interpret, and the behaviour questions answer themselves: if unionAll is just concatenation, then nested unionAll needs no separate rule. All of these functions return partial rows, so any of them fits any slot that expects rows.
• That rule of thumb settled two open questions. A parent should never have to care whether its child is a unionAll or a select — so a unionAll producing no rows behaves exactly like a select producing no rows, which is inner-join semantics. And forEachOrNull does not return nothing: it returns exactly one row with every requested column explicitly null, which is what a left outer join would give you.
• Empty select came up: error, or empty result? The point that closed it was that a ViewDefinition is a FHIR resource, so an empty select is already invalid against the logical model — you cannot reach it through a valid resource at all. The reference implementation used to throw and was changed to return empty, and neither choice is obviously better. The decision was to leave the behaviour undefined rather than legislate something FHIR already excludes.
• A live bug: with collection: true, the old reference implementation returns a bare value when a patient happens to have only one given name, instead of a one-element array — it shapes the output from the data rather than from the declaration. Agreement was that collection: true must always produce an array. No duck typing; that is the whole reason the flag exists.
• The test suite is being restructured — tests curated in JavaScript and generated out to JSON, with the old suite parked in a legacy folder. The tension is that not everyone implements in JavaScript, so contributors want to drop JSON tests straight in. The request back was to always publish the curated set as JSON so anyone can load the latest one, which is what the tests folder now is. Pathling goes the other direction, treating the JSON as the source and generating parameterised JUnit tests from it. The argument for curation was that throwing tests into a pile is easy, but keeping them coherent — one feature at a time, so an implementer can see what they have covered — is the actual work. Left open for later: whether ofType() takes a FHIR type or a FHIRPath type (FHIR.string versus string), with the instinct being to narrow FHIRPath but never diverge from it.