llrb | LLVM-based JIT Compiler for Ruby | Compiler library

Why the invariant is the current node is red or the current.left is red?

This is a choice and characterizes the algorithm. There is of course no guaranty that this invariant is true if you just blindly move down the tree, as you risk to arrive at a spot where the current node and its left child are both black. But this algorithm sets as a goal to maintain this invariant, as it helps to stay within the rules of a valid black-red tree while still manipulating it.

Why can't we move to the left if the current = red, current.left = black, current.left.left = black?

If we would move to the left, then we would arrive in a state where both the current node and its left child would be black, which would violate the invariant.

Why a color flip would maintain this invariant?

When the algorithm arrives in the above "blocking" state, a color flip will turn the current red node black, and its children red. So the invariant is maintained (the left child is now red), and we can now move left while keeping the invariant: after moving to the left we get a state where the current node is red.

Note that this color flip might bring the tree in an invalid state, as (before moving down) the current.left.right node might be red, and as it is a child of a node that became red by the flip, this is now violating the rule that a red node may not have a red child. The article goes on to explain how the algorithm will resolve that invalid state...