The tests also show the peculiar way of how some unfinished records are parsed today. Consider these cases:

{ F1 =
  F2 = 2 }

{ F1 = 1
  F2 =
  F3 = 3 }

I'd expect them to be parsed as 2 and 3 fields respectively, with error recovery applied for the fields with missing expressions. What happens instead is fields following the unfinished ones are parsed as = binary expressions (AST: 1, 2) or even sequences of them (AST).

I doubt that there's many actual code written like this. We've seen this tree shape before during typing and it made it much harder to analyze this unexpected structure in the tooling.

It's possible to change the structure into the more expected one, but it'd be a breaking change. To me it fits into the strict indentation changes in F# 8 with the exception that there was no warning before. We could probably try requiring additional indentation in record fields expressions:

// good
{ F =
    1 }

// bad
{ F =
  1 }

Or at least do the rewriting as it's currently done for the first field:

{ F1 = 1 // this is parsed as binary expression and rewritten to a field binding
  F2 = 2 } // subsequent fields are parsed as field bindings

What do you think?

I doubt that there's many actual code written like this.

Well, that's famous last words..."don't think it's going to break anyone".

/azp run