nil is like the absence of a value, reified into a value. Reading a variable that doesn't exist produces nil, and assigning nil deletes the variable.

Having a value that, when assigned to a variable or property, elides or deletes it is actually a desirable feature in MHO. Arguably, JavaScript's `undefined` should act like that, or nowadays more probably a well-known symbol. It's at any rate a nuisance that introducing one cavalier 'simplicity' (you can access `d.x` even when it does not exist, but you'll get `undefined` as value) causes so much accidental complexity (now you have to distinguish between so many fringe conditions (does `d` have a key `x`? does `d.x == undefined` mean `x` is set on `d`?). OTOH if you don't have a value that deletes a key from an object, then you'll have to special-case that operation because `delete d.x`, apart from being revolting syntactically, only exists as a syntactical construct.

Lua tables make no distinction between a table value being nil and the corresponding key not existing in the table necessitating hacks like: http://lua-users.org/wiki/StoringNilsInTables

Yeah, that's the point of nil. If you're trying to store it in a table, you're just fighting the language. Is there a good motivation for doing that?

I've done this on two rare occasions: round-tripping 'null' in JSON and 'NULL' in database queries.

My solution, which was perhaps overly cute, was a table canonically named No, which is callable such that No(nil), No(false), and No(No) all return true.

So I could say

   if No(value) then

When I needed to do conditional logic which excludes those reified null values, which isn't often.

> What makes Lua a bit different from other script languages is that 0, "0", "", {} e. t. c. are not false in Lua.

In Ruby only nil and false are falsey, everything else is truthy.

Same as Scheme.

nil is not fasley in Scheme. There is no falsey is sense that only #f is false :)