As usual, yet another missed optimization in the JIT. Report it to the developers of whichever JIT you're using (presumably Microsoft), especially if it comes up in real use-cases. But probably they tuned their JIT this way on purpose, presumably because it's not super common for real code to have such useless if statements. Certainly happens, but most ifs aren't useless.

The general answer to this and your previous questions (about optimizations that C compilers find but C# doesn't) is that JITs have to compile fast, and don't have the time to search for as many optimizations, so you should expect crap like this.

Why 5? Compilers frequently use heuristics on code-size or maybe number of branches to make decisions, perhaps in this case whether to try looking for some commonality between branch paths. In your case, 5 if statements was enough to push past some threshold for some heuristic. If you were investigating an open-source JIT, you could if you wanted dig in and find out specifically where in the source code it made the decision.

Especially for a JIT where compile-time more directly trades off against quality of optimization, skipping a pass that checks for that could make sense. But it doesn't for ahead-of-time C compilers; if you tell them to optimize, they will.

So anything that MSVC can optimize but C# doesn't is likely just a heuristic choice made to keep the JIT fast. IDK if MSVC is a good benchmark, but it's not the most aggressive or good optimizing compiler, compared to GCC and clang.

As @PMF mentioned in comments, this is actually an optimization the C# compiler proper could have made in the IL, instead of leaving it for the JIT. But probably most cases where it happens in real programs (that aren't on purpose written redundantly), it's only visible after things like inlining.

Still, this would be one way for MS to implement an optimization (that works for this intentionally-redundant case) without hurting the JIT-time vs. asm-speed tradeoff.

Going into a bit more detail here as to why the optimization does/doesn't happen depending on the number of ifs:

The optimization that occurs with the 1-if version actually seems to occur at compile time, since the IL produced in this case didn't contain any conditionals (it does contain some redundant loads of values that are simply popped later, but clearly the JIT is able to eliminate these from the generated code). In fact, all of the IL dumps you've given show that the compiler is optimizing away the last if, so the number of conditionals/returns in the IL is one fewer than the number in the C# source (this is relevant later). As others mention, the compiler should probably be optimizing away all the redundant conditionals, not just the last one, but let's try and work out why the JIT is doing what it's doing here.

The question therefore is: what's different in the JIT at 5 ifs that causes it to be optimized where fewer than 5 ifs aren't? Determining this pretty much requires building the .NET runtime from source in debug mode, then using the JIT-dumping functionality to see into exactly what the JIT is doing as it compiles the method. Having done this, the first obvious difference between the 2 and 5 if versions is that in the latter case, an early JIT phase kicks in which merges returns from the method, and since all the returns are the same, they are all merged into a single return block. Later phases of the JIT are then able to determine that the conditional jumps are redundant and so eliminates all of them as well, and the resulting native code is the simple mov eax,1/ret that we expect.

Now that we suspect it's return-merging that is the key to triggering the full optimization, we need to determine why 5 ifs is the magic number. This turns out to be relatively easy - there's a hard limit of 4 returns in a JITted method (see: flowgraph.cpp#L2127). While the 5 if version actually has 6 returns in the C# source, recall that the compiler optimizes away the last if, leaving just 5 returns in the IL, so it's only the 5 (or more) if version that exceeds this limit and causes the return-merging to kick in.

Finally we can test the hypothesis by rebuilding the JIT with the limit on the number of returns reduced, and see whether it optimizes the 2-4 ifs cases properly. Unfortunately it's not quite as simple as just changing the JIT's maximum number of returns to 1, because this triggers slightly different return-merging behaviour, so we'll try setting the maximum number of returns to 2, and I can confirm that it does then correctly optimize the 3 and 4 if versions as we expected.