GeezerVison

I'd rather this be split into more ifs than cram the conditions into one boolean expression.

Alternatively, break each subexpression onto its own line and explain each of them independently. For instance:

// We've found something in the 'locals' table, but we are sensitive to location in whether it is valid to use
// this entity.
//    - A non-type entity (i.e. values, namespaces, and aliases) is unconditionally resolved.
//    - A type parameters are visible throughout the entirety of a declaration, and are resolved.
//    - A local type found in any declaration *other than a function* can be considered resolved.
//    - A local types found in a function is only resolved if it was used *within the body of the function*.
if (!(meaning & SymbolFlags.Type) ||
    !(result.flags & (SymbolFlags.Type & ~SymbolFlags.TypeParameter)) ||
    !isFunctionLike(location) ||
    lastLocation === (<FunctionLikeDeclaration>location).body) {

In general I think it is perfectly fine (and often preferable) to have multi-line boolean expressions instead of multiple if statements with "explaining variables". The latter just make the code even more complicated to look at. There's nothing inherently simpler about multiple if statements compared to multiple boolean operands separated by && and ||. Quite the opposite actually, since with boolean expressions you know there aren't any side effects or other oddities you have to worry about.

I do agree that in this case putting each condition on a separate line might make sense.

I disagree. I think that multiple if statements are actually simpler. They allow you to examine each clause, one at a time. They let each clause be simple explained. They do not require you to think through multiple different forms of boolean expressions in each clause.

Some minds (mine included) tend to have the problem where we see one expression, and then 'stamp' what we saw there on the next in a complicated clause. So if one expression does || and the next does &&, or one uses ! while the other does not, then it's very easy to 'trip' over the expression, forcing the need to go back and scan and understand the expression over and over again.

At this point, we've been using this code for around a year at this point, and there are still comments/complaints on the PRs about the clarity of the code. At this point, i think we should accept that these constructs are difficult for many team members to read, and we should err on the side of making the code as maintainable as possible for the team as a whole.

We'll just have to disagree here. If the team has problems reading multi-line boolean expressions then I think we have a bigger problem. You're advocating turning simple and functional boolean expressions into multiple imperative if statements with temporary variables. I think that is exactly the wrong way to go. Whenever I see those I always wonder if I'm missing something subtle (which imperative code is full of), because otherwise it would just be written as a simple boolean expression.

I am confused about the purpose of the getStatementFlags approach. Why is it better than having isStatement and isModuleElement just make the decisions for themselves? Is it so that there can be just one place (instead of two) to account for all the node kinds here, so we don't forget any?

The problem is modifiers. When modifiers are present we can't tell from the first token what we're looking at. So we need to look ahead, but we don't want to do that more than once. And, as you say, when everything is in one place we're certain that there won't be any subtle differences.

Is this for anonymous class expressions?

No, it's for the anonymous type created for the static side of a class.

Ah yes, because previously the static side of a class could never get instantiated.