Topics discussed:

• The group started voting on a feature list — everyone adds a column and marks each feature -1, 0 or +1 for whether it belongs in the first release. It is not a vote on whether a feature is good, only on what has to be finished before a line gets drawn. The motivation was blunt and came from implementers: people are holding off because the spec keeps moving. One team's feedback was 'we implemented this, now it's renamed, and renamed again' — so freeze it and ship a version.
• What the milestone actually commits to is: no more renaming. The plan is semantic versioning — no breaking changes within a major version, with the right reserved to do a 2.0 that does break. Then John pointed out that calling it 1.0 collides with the older spec already called SQL on FHIR v1, so it will be 2.0 instead. Cheap fix, and it sidesteps years of explaining which version one you mean.
• That naming clash is real and unresolved. v1 maps FHIR resources onto a database schema; v2 is a way of saying which fields you want out of a resource and getting a flat view. They are different problems, and people told 'we support v1 and are implementing v2' reasonably conclude they should wait for v2. The counter-argument was that only a small, technical group knows v1 well enough to be confused, and they will step over it; the much larger audience arrives fresh. v1's content now lives inside v2 as informative material.
• A clear statement of where the spec stops: the point is to reach into the FHIR data model and produce a simple projection, then let plain SQL or Spark SQL do the final joining and transformation. It would be tempting to keep going, but people need help with the FHIR-specific parts, not another general-purpose query language. Beyond the first milestone, the sketched roadmap was a query definition resource — if views are tables, people will want to publish the report queries that run on them — and possibly a model definition.
• Two threads that stayed open. Bidirectionality: if a view projects FHIR out, could you run it backwards? The encoders already give a lossless round trip between FHIR and a Spark schema, but use-case-specific views do not — you would have to run the view in reverse, and nobody knows how. And the columnar layer, 'layer zero': the argument made was that the schema layer and ViewDefinition are inseparable work streams, that you cannot define the abstract layer and tell people they are on their own for the actual column format — with bulk export waiting on a Parquet answer.