With regards to static analysis, I don’t think there would be a fundamental problem with static analysis of context blocks beyond having to analyze decorated constructs in general. As long as the analyzer knows the identity of a decorator, then it knows the types of the callbacks that are involved in its decorated constructs.

But it’s true that F# computation expressions are slightly more verbose than bespoke LINQ FLOWR/FLOWS syntax. That’s the price of its being generic.

i.e., in F# you can do:

query {
  for student in db.Student do
  groupBy student.Age into g
  select (g.Key, g.Count())
}

Which handles into based on whether AllowIntoPattern is set on the groupBy method of the builder.

Or

query {
  for student in db.Student do
  join selection in db.CourseSelection
    on (student.StudentID = selection.StudentID)
  select (student, selection)
}

Which parses on as the join condition because it's specified by JoinConditionWord.

F# made this much more customizable than C#, which has explicit syntax for group, join, into, on, select, etc. To do this in JS could mean parsing arbitrary patterns of identifiers and expressions and then enforcing them after the fact:

CoverComputationJoinLikeStatement:
  Identifier BindingIdentifier `in` LeftHandSideExpression Identifier LeftHandSideExpression

Where the first Identifier has to match a custom operation keyword, and the 2nd Identifier has to match that operation's JoinConditionWord. Its a level of complexity that I think many would balk at

Plus I'm not sure this would fit well with existing JS expressions/statements...

@query do {
  for (const student of db.Student) {
    join (const selection of db.Selection on student.studentId === selection.studentId) {
      select #[student, selection];
    }
  }
}

// or
@query do {
  for (const student of db.Student)
  join (const selection of db.Selection on student.studentId === selection.studentId)
  select #[student, selection]
}