I see a couple of competing arguments here.
(1) It may be better to treat t[i,j] as being equivalent to t[i] in the absence of __index/__newindex. Combined with the above discussion about multi-return functions, this would be the most compatible with old code.
(2) Provide a meaningful default implementation for t[i,j] so that Lua has a multidimensional compound data type built in.
I don't think that it's "absolutely useless" without either of these as Egor asserts, but it's certainly inconvenient. At the very least, it would be nice if the table library provided a predefined multi-index metatable you could assign to a table, or a function that returns an empty table already configured with such a metatable.
We have
t(i1, i2, ...) --> getmetatable(t).__call(t, i1, i2, ...)
This is always called.
We are considering something like
t[i1, i2, ...] --> getmetatable(t).__index(t, i1, i2, ...)
t[i1, i2, ...] = v --> getmetatable(t).__newindex(t, v, i1, i2, ...)
They would be incompatible both because of the t[f()] issue, because the parameter order in __newindex(t, i1, v, i2, ...) is awkward, and because these methods are only called when the table index doesn't exist.
Should we instead make
t(i1, i2, ...) = v --> getmetatable(t).__lvaluecall(t, v, i1, i2, ...) ?
This solves the l-value problem with the notation, makes the meaning of t(f()) = v completely obvious, and would always call the metamethod, just like t() currently does.
Since there are no breaking changes involved, anyone would be free to design a multi-index translation scheme and there even could be a predefined implementation as you suggest.
Now if somebody finds a way for __lvaluecall to receive multiple *values* along with multiple indices, we could even have tables that store and return multi-dimensional data.
Not sure how to work this out, but it sure would be cool.
