Fix stability policy

[eemeli]

When #472 was merged, it ended up including changes suggested by @aphillips in #472 (comment) that had not been fully reviewed. This PR is about fixing issues related to that late addition.

Right now this is mostly editorial, and re-introducing a phrase that was dropped on merge:

Later specification versions MAY make previously invalid messages valid.

However, we should also decide here what to do about this indented note that was included in the change:

Note: future versions may define new keywords.

For this to be valid, we need to find a way to make it play nice with this other bit of policy:

Updates to this specification will not introduce message syntax that,
when parsed according to earlier versions of this specification,
would produce syntax or data model errors.

In other words, we need to come up with a syntax that allows for space for keywords to be reserved, so that a current parser won't syntax-error with them. At least thus far, each of our keywords associates with one of more subsequent expressions or patterns.

This is problematic with a syntax like our current one, which uses { at the top level as both an expression and pattern start, depending on the context. Essentially, it's not possible to determine if keyword {foo|bar} is valid without knowing if it's meant to be processed as an expression or a pattern.

With a syntax as proposed in this alternative, this problem becomes at least tractable.

This note should not be left as is; either it needs to be dropped, or it needs to be made explicitly normative.

[aphillips]

LGTM. Thanks for getting back to this before I did.

[aphillips]

@eemeli any reason not to commit this? I expect that we'll need, as a WG, to review the stability items (particularly near the end) and have added that as a task to the task list.

[eemeli]

This bit from my earlier comment should be addressed:

This note should not be left as is; either it needs to be dropped, or it needs to be made explicitly normative.

[aphillips]

@eemeli Agreed. Note that #482 exists now for the syntax part.

It is possible to define a keyword syntax that is forward compatible parsable but whose meaning is unknown. Is it worth the effort? I think it might be, since "never" is a long time and many languages have created new keywords later (sometimes much later). However, this will require greater work on the syntax, since that usually involves the concept of a "statement".

In the discussion of text-first syntaxes, to choose an example, starting a statement with # and ending the expression close might do that for declarations, with match being an outlier or potential outlier:

#input {something}
#local (something}
#unknown {something}
#match {expr} {expr}
when foo foo {still in the match...}
when bar bar {still in the match...}
when * * {still in the match...}
// implicit close

(If I had to guess what we might add, a likely candidate would probably be a loop construct or iterator, such as when building a ul or ol in HTML. This suggests a more complex syntax closer to match than to a declaration.)

So, net net...

I think the stability guarantee could apply only to syntax or at least that we should split this into two policy items:

• Updates to this specification will not introduce message syntax that would be
  considered syntax errors in earlier versions of this specification
• Updates to this specification will not introduce message syntax that makes
  existing data model items invalid.

I don't think we can guarantee stability of the data model as the current text has it: that would prevent us from ever adding something that isn't in the current data model. That's different from "existing syntax items won't produce something different".