I'm not sure if I can make it "warning lua" instead. It'd make sense, certainly.

Sapient: It's only partially implemented. I don't see how just rearranging documentation could get similar gains. Also, if you're worried about typing more characters, you could always do as before and write eg "local T = wml.tag". I don't think most of them are more characters though? For example, "wml.variable.get" is shorter than "wesnoth.get_variable".

The purpose of the idea is to provide a cleaner and more organized API which is grouped by what category of thing the API applies to (to be more intuitive for developers using the API) rather than grouped as they were by which part of the code they originate in (a distinction which sometimes makes things easier for the developers making the API, but is of little importance to those using it, nor, in my opinion, should they particularly need to be aware of it). I tend to favor APIs which are intuitive for the API user, even if that means that internal code from both C++ and Lua gets put in the same file or table. I should clarify that it was not my intention to have deprecation warnings added until (A) there is broad consensus to prefer the new organization over the old, (B) the new, more organized API has been around for a while, (C) all mainline code is up-to-date with it and (D) the add-on developers are mostly working with it as well. (Also to be clear, even after deprecation, I don't think the old API as a whole should be removed until the vast majority of add-ons on the official server for whatever version we're up to at the time are no longer using it. On the other hand, certain functions, proxy objects, or or other individual API operations from the old API can be removed or updated individually on a case-by-case basis as the code or architecture changes no longer support that particular paradigm, as they would have been in that case anyway.)