Why does the Lua idiom x = a and b or c return the wrong value when b is false?

and and or return one of their operands, not a boolean. a and b gives a if a is false or nil, otherwise b. a or b gives a if it is anything other than false or nil, otherwise b. Both short-circuit, and and binds tighter than or, so c and x or y is (c and x) or y.

When c is true and x is false or nil, (c and x) is falsy and the expression falls through to y. The idiom is only a ternary when the middle value can never be false or nil.

For defaults, test for nil explicitly whenever false is a legitimate value: local pullup = opts.pullup followed by if pullup == nil then pullup = true end.

x = x or default is fine for numbers, strings and tables, because only false and nil are falsy in Lua. Note that 0 and the empty string are truthy, so count or 10 keeps a count of 0, unlike the equivalent expression in JavaScript or Python.

For the general two-way choice, the safe forms are an if statement or a tiny helper. If you swap the operands so the value that may be false sits last, the one-liner works again: not cond and b or a is correct as long as b is never falsy.

A helper such as local function choose(c, a, b) if c then return a else return b end end is always correct, but remember that it evaluates both a and b before the call, so it loses the short-circuit behaviour. That matters if one branch is expensive or has side effects, like your compute(key).

The cache case needs to tell "not cached" from "cached false". Compare with nil directly: local v = cache[key], then if v == nil then v = compute(key); cache[key] = v end. That still cannot cache a nil result, because assigning nil to a table field removes the key. If compute can return nil, store a unique sentinel in its place, for example local NIL = {}, and translate it back when reading.

A quick way to check any of these expressions is the standalone interpreter: print(true and false or "x") prints x, while print(false or false) prints false.