The macro to use exceptions is what allows you to do things like actually use a C++ class in code that is meant to be called from Lua, allowing you do do things like check for valid input and throw Lua errors while still cleaning up your stack. It might seem small, but it's the difference between able to safely write normal C++ style code or being stuck writing C style code with Lua. Your whole point was that you cannot interface between the two. That "macro hackery" is there to be able to do it.
Lua uses some purely internal macros (triggered when you use a C++ compiler to build it) to have a basic interaction with C++ exceptions, yes. However, for some other reasons (especially in the area of game development) the usefulness of that is severely restricted.
First, in our domain exceptions (whether to use them at all, or not) is a topic of hot debate. There is quite a few people (especially among the professionals) who argue most strictly against them. I don't follow that line, by the way.
That said, even if you use exceptions you do not need to compile Lua as C++ code. Make your calls into Lua as pcalls (or set your own error handler) and make sure your C++ code cannot throw into Lua (should be trivial by placing an adequate try/catch->luaError block in your automatic glue templates). You could of course ask: Why go through that? Here is the thing: although Lua can interact with C++ exceptions after a bit of persuasion, LuaJIT cannot. If you are using it or want the option for the future, you better stick to the no-exception-way.
When I downloaded Lua myself, I just threw the code in a static library and built it. I wasn't even really aware of what else I should try. It's probably more common than you think that other people did the same thing.
I like building my stuff as a single executable as well. However, building Lua as C++ does not solve the problem. You now have Lua and the rest of your code using the same ABI (provided there are no important differences in how you compile the individual static libraries being linked). They still talk to each other using a C API. Sure, you can extend that API (you have the source, after all) but at that point it stops being Lua and is BitLua, PinkLua or unnamed-largely-compatible-Lua-fork. You cannot just replace it with a new version or different fork. The Lua developers won't add a C++ interface because the ABI thing would be a huge issue for everyone not using static linkage by default (or even sticks to simply downloading the DLL).
"[background=#fafbfc]Lua is written in C and thus cannot interact interact with C++[/background]
" - You seem capable enough to be able to come up with plenty of examples of things written in C that interact with other things written in C++, so this is clearly false. I could name a bunch of stuff statically linked together, and then get into dynamic linking, and then what about inter-process communication? Distributed applications? The Internet? Interact is a broad term. I actually don't think I've ever worked on anything substantial that was pure C or pure C++. Everything has had some of both.
The statement was written for someone who was in well over his depth and thinking they had a Lua problem while they had a fundamental parts of the language problem. ApochPiQ technically solved it but in my opinion the that was insufficient to make the OP realize the pit they are in. When writing the post I did have the issue expanding to several paragraphs but I found covering all bits I would need to touch would take much more time than I could give at that time. So I instead went for a shortcut (especially since all of this would go over the OPs head at this point) which mentions the important keywords to start your own search for enlightenment. It's a convenient lie, yes, and I think we have expanded on that by now.
In my mind the post was in For Beginners and I considered it worse to open completely useless (at this point in time) tangents for the OP.
Yes, you wouldn't hand a member function pointer to Lua, because in general, in C++, a member function pointer is a worthless thing to pass around, because it's too specific. The type of the class is part of its type. It doesn't matter whether Lua is pure C or if it was an idiomatic C++ object-oriented-designed interpreter, it still almost certainly wouldn't have an interface to use with your member function pointer. Saying the reason it cannot do it is because it's C is misleading and wrong.
I still maintain it is because of the C++ ABI. The ABI is a mess to deal with, a huge one. Even projects which are internally implemented in C++ sometimes pipe themselves through a pure C API because there is no good, general solution.
If there were some common ground of C++ ABI you could rely on, I see no reason why there could not be some quick luaL-utility-functions to deal with the issue (after all, there are already several luaL-functions which you strictly don't need but which help your quality of life in the general case.