As you see, each Lua sugar disobeys some of your rules.
Does this mean that each existing Lua sugar is not "really useful"?
Lua (as any other language) is a set of trade-offs.
IMO, your rules are correct in general, but too idealistic for the real world.
While I disagree with some of your analyses, that doesn't really impact my own opinion on the answer.
I think the answer is "yes, some existing sugar isn't really useful." But not everything has to be a 10-out-of-10; if the benefits (including how often such a feature would be useful) outweigh the maintenance burden, then some weaknesses in the "really useful" scoring are a meaningful tradeoff. It's still a good rubric to think about when designing features.
As for those disagreements...
On the first one, I think your analysis on LR4 is wrong -- it isn't obscuring a fundamental concept; it's highlighting it. The point of the : operator is to emphasize that a table can contain functions intended to operate upon itself. Requiring the programmer to express that concept of "self"-ness in the function call distracts from the intent of that relationship.
On the second one I also think your analysis on LR4 is wrong -- neither the [] nor the . notation are more specific to "just a field in a table". Rather, . emphasizes the more static nature of the field (you know at compile time which field you want) while [] emphasizes the more dynamic nature (it accepts an _expression_, which can vary at runtime), so even if the implementation is the same for both of them, they aren't obscuring anything, just providing different perspectives on it.
On the fourth one, again LR4: I don't think the concept that globals are a table isn't fundamental. It's more of an implementation detail, and the distinction between those and file-level locals I think kind of highlights that. In any other language, the ability to reflect on the global scope using standard language tools would be considered a bonus feature, not fundamental.
And on the last one, I disagree with your analysis of both LR2 and LR4. The "correct" meaning may be how it works semantically, but expressing it that way IMO obscures that meaning more than the "local function" syntax does, because the "function" syntax itself appears to be a declaration that conflicts with the previous "local" statement. The sugared form is LESS confusing than the unsugared form.
/s/ Adam
