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.