I find nothing weird about lexical scope and the 1-based arrays don't bother me at all, but iterators are awesome.

To me, Lua's most annoying feature is that tables are the only data structure. When I was first learning Lua, I thought it was pretty cool to have one and only one very versatile data structure. Nowadays, I find it's more trouble than it's worth. Indeed, the fact that pairs() and ipairs() are separate functions demonstrates that tables are a leaky abstraction: you have to constantly think about whether a table represents a hashmap or an array or both. Luckily, Lua is very extensible and there are several ways around it.

All in all, I find Lua to be an excellent language. I wrote a utility in it at work, and most of the veterans started sweating when I told them it was written in some language they'd never heard of. As soon as I showed them the code, they were visibly relieved. "We can read this and understand it," they said. Lua's readability is a big win.

To me, this harkens back to the debate about the length of a table if it has nils in it.

The Lua table is not the be-all and end-all of data structures (though it is quite versatile out of the box). However, it can be the basis for any kind of data structure you can imagine. Trees of all varieties, priority queues, etc.. The strength of the language is that there is just one fundamental data structure, and it is implemented well, and it has good syntax support in the language. There is no mental overhead like with Python where you have to use square brackets for lists and curly braces for dictionaries.

Seriously?

Lua has pretty nice and lightweight prototype OOP, which boils down to a few uses of : instead of . on tables and setting the __index of the metatable to be the parent table.

That's not to say python is not an excellent language, just that lua is a lot simpler.

1-based: you're numbering. In Lua, an array is an optimization of a hash, and the items inserted without explicit keys are numbered one, two, three…

What you consider a minor gripe, compound assignment operator, I personally think is a flaw in the language same goes for bitwise functions instead of operators. Here is an example I posted earlier on twitter.

object = object + other

"object" and "other" here are full userdata and the code is going to malloc a new userdata and also create a new object in C/C++; which is straight away going to over write the original instance. Huh? why? += makes so much sense.

Each to there own, I can fix my issues using patches but it would be nice if I did not have to.

  t = {foo()}

  function capture_values_internal(idx,t,remaining,val,...)
    if remaining == 0 then
      return t
    else
      t[idx]=val
      return capture_values_internal(idx+1,t,remaining-1,...)
    end
  end
  
  function capture_values(...)
    return capture_values_internal(0,{},select("#",...),...)
  end
  
  t = capture_values(foo())

  function capture_values(...)
    local n,t=select("#",...),{...}
    for i=0,n do
      t[i]=t[i+1]
    end
    return t
  end
  
  t = capture_values(foo())

No. Not having a real numeric or array type is serious, '1-based arrays' is just a minor quibble about syntactic sugar.