The nullish coalescing operator DOES NOT apply to this case:

The nullish coalescing (??) operator is a logical operator that returns its right-hand side operand when its left-hand side operand is null or undefined, and otherwise returns its left-hand side operand.

See the docs

In this case you have a simple union of type Day | 0, you just have to check manually:

for (let i = 0; i < 4; i++) {
  const item = daysArray[i];

  if (typeof item === "number") {
    console.log(0);
  } else {
    console.log(item.dayNumber);
  }
} 

I spent a long time trying to write out the mechanical explanation for why particular expressions like expr1 || expr2 && expr3 act as type guards in certain situations and not in others. It ended up becoming several pages and still didn't account for all the cases in your examples. If you care you can look at the code implemented for expression operators in microsoft/TypeScript#7140.

A more high-level explanation for why this limitation and ones like it exist: when you, a human being, sees a value of a union type, you can decide to analyze it by imagining what would happen if the value were narrowed to each member of that type, for the entire scope where that value exists. If your code behaves well for each such case analysis, then it behaves well for the full union. This decision is presumably made based on how much you care about the behavior of the code in question, or some other cognitive process that we cannot hope to reproduce by a compiler.

The compiler could possibly do this analysis all the time, for every possible union-typed expression it encountered. We could call this "automatic distributive control flow analysis" and it would have the benefit of nearly always producing the type guard behavior you want. The drawback is that the compiler would require more memory and time than you'd be willing to spend, and possibly more than humanity is able to spend due to the combinatorial explosion that happens as each additional union-typed expression has a multiplicative effect on required resources. Exponential-time algorithms don't make for good compilers.

At times I've wanted to be able to hint to the compiler that a particular union-typed value in a particular scope should be analyzed this way, and I even filed a request for such "opt-in distributive control flow analysis", (see microsoft/TypeScript#25051), but even this would require a lot of development effort to implement and would deviate from the TS design goals of enabling JS design patterns without requiring the developer to think too hard about control flow analysis.

So in the end, what TypeScript language designers do is to implement heuristics that perform such analysis in limited scopes that enable conventional and idiomatic JavaScript coding patterns. If code like (a ?? null) && fs(a) is not considered idiomatic and conventional enough for the language designers (this is partially subjective and partially depending on examining a corpus of real-world code), and if implementing it would result in a major compiler performance penalty, then I wouldn't expect the language to support it.

Some examples:

• UPDATE FOR TS4.4; the following is fixed in microsoft/TypeScript#44370 microsoft/TypeScript#12184: support "saving" the result of a type guard into a constant (like your something example) for later use. This is an open suggestion marked as "revisit" with the ominous proclamation by a language architect that it would be difficult to do it in a performant manner. This might be idiomatic, but it might be hard to implement effectively.

• microsoft/TypeScript#37258: support successive type guards where narrowings are performed on multiple correlated variables at once. It's closed as too complex because to avoid an exponential-time algorithm you'd need to hardcode it to some small number of checks which wouldn't be very beneficial in general. The suggestion by the language maintainers: use more idiomatic checks.

So that's the closest I can get to an authoritative or official answer on this. Hope it helps; good luck!