I'm struggling with the problem that this is solving. What thing does it do that lua does not already do?
Consider that strings are wrapped in an object where they get the string library's methods. This makes sense because it's hard to imagine using strings in any other way, except as strings. (Even here, it is instructive that unicode characters break some of string library's intent.)
However, tables are a generic interface for everything. A "by default" hardwiring of the table library puts too much emphasis on those methods and the use of a table as a dictionary or indexed array.
In the same way, making "for k, v in t do..." has the same problem. In the name of a more "natural" syntax, to my thinking, you've obfuscated the fact that a function that returns a function that knows how to iterate "t" is being called. In this one case, passing a function to "for", but not "t" (which could be callable), but "t"'s "__iter" function, or if not that, then its "__pairs" or "__ipairs?".
"pairs", "ipairs" or some other iterator function made it explicit that I was iterating the object in a certain way. I could also say "for k, v in myobj:tier() do..." and accomplish the same thing, more clearly. (For that reason, I like the idea of writing explicit iterators, rather than redefining ipairs/pairs, but I'm probably in the minority on that one)
This proposal doesn't break anything (much?), and it does makes the code a bit shorter. I can't see how it makes anything clearer.
My $0.02.
