Certainly true, but it is usually distributed and often used as a dynamic library.
Sure, if you link it statically as part of your customized build, a lot of things go (same goes for a lot of other projects), but not right out of the box (teaching Lua to deal with member function pointers feels like a decidedly non-trivial change and still leaves the whole 'who deals with this and lifetime and ownership?'-issue floating around). And any change you do there could become very annoying when you need to upgrade to a new Lua version. I would not do that myself, least of all advise someone markedly newer to try it.
Also, "capable of building in C++" sounds a bit grander in my mind than it really is. It has a very basic support to avoid C++ name mangling and some macro hackery to switch between exceptions and setjmp/longjmp.
There is a lot of "you could of course also..." in that whole area but considering the OP was confused by the member function/free function issue already I did not consider it useful to open those can of worms. They are best left for after you gained a few skill points.
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.
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.
"Lua is written in C and thus cannot interact interact with C++" - 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.
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 agree that the OP does appear to be ready to tackle writing a language binding at this time. However, someone else might be reading this.