Topics discussed:

• ViewDefinition can't just be declared a resource because FHIR refers to resources by short name almost everywhere — reference targets, search parameter targets, capability statements — and most of those places won't accept a full URL. So the name has to be controlled centrally, or ten groups define ten different things called ViewDefinition and nobody knows which is authoritative. A registry for this already exists, and ViewDefinition is already in it — put there speculatively while someone was tinkering, not authorised.
• The bar turned out to be higher than the FHIR Community Process the group runs under today: a resource definition has to live in an IG that has been through HL7 International's STU and balloting process. That leaves two routes — file a PSS and become an official project sponsored by FHIR-I, or ask FHIR-I to publish a separate IG holding just the resource definition and keep the group's own IG outside it. The group chose the first, on the grounds that the second means handing the thing over to somebody else's process.
• Someone asked plainly what formalising would cost day to day. The honest answer: the calendar moves onto HL7's, you need a sponsoring work group, and spec changes need Jira tickets and votes. In practice FHIR-I runs block votes — thirty dispositions at once, and almost nobody objects, because the people who care are already the people doing the work. Other work groups vary wildly; some grind through every ticket live on a call because that's the only place their members show up.
• The framing underneath all of this is that a large part of the industry insists FHIR is a closed world: if a US Core diagnosis cites a resource you've never heard of, you can't parse it, so it isn't a valid US Core diagnosis. Splitting things out of core is therefore about modularising a core that stays closed, not about extensibility. Someone pushed back on calling the result an "incubator" — that implies unfinished, when a module might legitimately stay separate forever — but "module" is already a taken word in FHIR.
• The repeat directive exists because ViewDefinition has no answer for recursive structures, and QuestionnaireResponse nests to arbitrary depth: today you hand-unnest and your view ends up coupled to however deep your data happens to go. The proposal takes one or more paths, walks down the tree collecting each, unions them, and applies the selection to the union — you need the multiple paths because questionnaire items live at both item.item and item.answer.item. Left open: it behaves more like FHIRPath's repeatAll than repeat, a SQL transpiler has to solve the recursion somehow (CTEs, or possibly Postgres JSON path), and the order has to be spelled out when repeat and forEach land on the same node.