¿Motivo detrás del error de sintaxis de modo estricto al eliminar un identificador no calificado?

Tengo problemas para entender por qué, en modo estricto, se produce un error de sintaxis cuandodelete se utiliza en un identificador no calificado.

En la mayoría de los casos, tiene sentido ... si está declarando variables de la forma habitual con lavar palabra clave, y luego tratando de usardelete en ellos, en modo no estricto fallaría silenciosamente, por lo que tiene sentido que el modo estricto falle con un error en esos casos.

Sin embargo, hay casos en los quehipocresía eliminar identificadores queson calificado:

(function() {

  // "use strict";

  var obj = Object.create({}, { bloop: { configurable: false } });

  delete obj.bloop; // throws TypeError in strict mode, silently fails in non-strict.

  console.log('bloop' in obj); // true

}());

El modo estricto debe hacer una verificación de tiempo de ejecución aquí, porque se lanza un TypeError cuando se encuentra esto. También hay casos en los quepuede eliminar con éxito identificadores no calificados en modo no estricto ...

// "use strict";

window.bar = 6;

console.log(typeof bar); // number

delete bar; // works in non-strict, syntax error in strict!

console.log(typeof bar); // undefined

De hecho, a mi entender, si puede eliminar o no las cosas (en modo no estricto) depende de lo interno[[Configurable]] propiedad, y no tiene nada que ver con identificadores calificados. Por lo que puedo decir, no hay manera en modo estricto de eliminar variables no globales que (como propiedades de la VO local)son configurable:

(function() {

  // "use strict";

  eval('var foo = 5;');

  console.log(typeof foo); // number

  delete foo; // works in non-strict, SyntaxError in strict.

  console.log(typeof foo); // undefined

}());

Entonces, mi pregunta es, ¿cuál es el punto de lanzar un SyntaxError cuando se usadelete en un identificador no calificado, cuando el TypeError se lanzaría de todos modos si la propiedad no es configurable? Esto parece una restricción innecesaria, y en algunos casos no parece haber ninguna otra solución que no utilice el modo estricto (tercer ejemplo). ¿Alguien puede explicar la motivación detrás de esta decisión?

Actualización: Me acabo de dar cuenta de que estaba pasando por alto el hecho de que directaeval las llamadas tienen su propio alcance en modo estricto, en lugar del alcance de la función de llamada, por lo que en el tercer ejemplofoo No se definiría en modo estricto. De todos modos, la verificación de tiempo de ejecución aún detectaría esto, pero plantea una pregunta complementaria: ¿no hay manera de tener variables locales configurables en modo estricto, como hacemos coneval¿Declaraciones de variables en no estrictas? AFAIK fue uno de los pocos usos legítimos deeval.

Respuestas a la pregunta(2)

Su respuesta a la pregunta