more "mental tax": interpreting code that uses `let` in many nested blocks

1.js

/*
not terribly difficult to predict which statements print what.
*/

function foo() {
   var a, b, c, d;

   if (true) {
      if (true) {
         a = 1;
         if (true) {
            b = 2;
            c = 3;
            if (true) {
               d = 4;
               console.log("d: " + d);
            }
            console.log("c: " + c);
         }
         console.log("b: " + b);
      }
      console.log("a: " + a);
   }
}

// will print:
// d: 4
// c: 3
// b: 2
// a: 1

2.js

/*
a little harder to trace visually to know what will happen. admit it: it takes some extra 
visual and mental processing to track which scope each variable is in, and whether the 
`console.log()` in each block will succeed or fail.
*/

function foo() {
   if (true) {
      if (true) {
         let a = 1;
         if (true) {
            let b = 2, c = 3;
            if (true) {
               let d = 4;
               console.log("d: " + d);
            }
            console.log("c: " + c);
         }
         console.log("b: " + b);
      }
      console.log("a: " + a);
   }
}

// will print:
// d: 4
// c: 3
// b: undefined
// a: undefined

I understand what's being demonstrated but I'm not sure it's entirely fair. Your examples have 1 function scope and 5 block scopes. Block scoping offers more scopes and thus offers more options/flexibility. That IS the feature right?

I'd argue it's not a whole lot harder than function scoping because you should be zoning in on the block scope in isolation, paying attention only to declarations within that scope. You don't even have to worry about declarations in any child scopes!

Here's a simple example that in many real world scenarios can cause problems:

function foo( bar ) {
    var baz = "yay";
    if ( bar ) {
        var baz = "nay";
    }
    console.log(baz);
}