Topics discussed:

• The JSON schema guidance and columnar schema pages predate where ViewDefinition landed. They are prescriptive about naming, data types and specific algorithms for serialising FHIR into other schemas, and much of that no longer matches how the spec evolved — the word used for them was confusing. The consensus was to pull them out of the core spec so the core stays small, let them regrow in a separate implementation guide, and keep outbound pointers so a reader building a data layer can follow the trail of breadcrumbs.
• Not all of it is dead. The genuinely general parts — contained resources, infinite recursion, choice types, date and float precision — are problems anyone building a data layer for FHIR runs into, and several implementations have already handled them the same way, such as capping recursion depth. The counter-proposal was to stop being general: pick one concrete target, Parquet, and say exactly how FHIR maps onto it, extensions included, rather than describing considerations that apply to everything and pin down nothing.
• A practical constraint on all of this: the old pages are referenced heavily from outside — vendor documentation, communication with partners — so whatever moves, the URLs have to keep working or redirect. Nothing currently planned breaks them, since those links point at the 1.0 spec, but a manifest of locations was suggested for anything done in future.
• A newcomer's read of the spec: it needs to say who it's for. The CQL spec was held up as a model, split into chapters by audience — one for authors, one for developers — with the deep material in appendices. Questions that went unanswered on a first pass included what "extensions are first-class citizens" actually means and how you'd go and find one. The follow-on suggestion was to treat new readers as a resource — have them fire over every question the spec fails to answer, and shape the text to answer them — because people who have discussed this for a year can no longer see the gaps.
• ofType with an invalid type argument: error, or null? The FHIR spec says only concrete core types are allowed there, but FHIRPath.js doesn't check and simply returns null. The distinction drawn was between a type that doesn't exist in FHIR at all — detectable statically, without any data, so it should fail — and something like Observation.value.ofType(markdown), a real type that just cannot occur in that position, where the bar for knowing that is much higher and null is more defensible. Underneath sits the general position that error handling is a SHOULD, since implementations surface errors however their stack allows and a rare failure shouldn't sink a run. The idea floated was a separate, optional validator role, strict where the runner is lenient, with its own thorough tests. Unresolved, taken to Zulip.