My latest project is a PC/SC and PKCS#11 driver framework. There are a few places in the C code, particularly the driver entry points before calling into Lua, where you can't bubble up an error context--you're limited to returning an error code to the caller--but for debugging and diagnostics you really want some context. Currently I just fprintf to stderr because it's not worth the hassle to call the logging code written for the Lua part of the drivers, but this new warning infrastructure provides a clear path for doing this--just replace the calls to fprintf with lua_warning (or a wrapper for vararg formatting).

It would be trivial to have done this myself, but it's one of those things you abstain from doing because you don't want the burden of making the choices (e.g. how to manage the global singleton hook), maintaining the code, and perpetually resisting the urge to refactor it.

My guess is that the warn global in the Lua environment was primarily added for symmetry with lua_warning. It's notable that there's no counterpart (AFAICT) to lua_setwarnf provided for Lua code. I think the warning API is principally a feature for C code.

I still think it's a dubious addition and will end up generating friction. It's the kind of thing people love to hate. For example, I bet it won't be long before someone complains you can only pass a single string rather than an object like with lua_error or multiple value like with lua_call/lua_yield. I won't complain about it, though. =)

EDIT: Reading the mailing-list and the code (grep for luaE_warning), it looks like this interface was principally added for the GC so __gc metamethod errors could be reported without throwing exceptions at random places in the code (i.e. where ever the application happened to be when the GC finalized an object).