Great! I do prefer to limit the #ifdef’s in the code, for readability, so if you find a way to replace some of these with equivalent shadowing in parser-inc, that might be good too. 
Hmm, that means that something’s going wrong with the automatic downcasting. The way this is supposed to work is this: when interrogate wraps a function that returns a pointer to a class that inherits (eventually) from TypedObject, then it also adds a bit of code to call ptr->get_type() before it returns, and if the TypeHandle returned by get_type() indicates a classname that it knows about, it will convert the pointer to the specified Python type before returning it.
So, if getGsg() is not returning a wglGraphicsStateGuardian, one of the following must be going wrong:
(1) gsg->get_type() (or, in Python, gsg->getType()) is not returning an appropriate TypeHandle that indicates
“wglGraphicsStateGuardian”, or
(2) Python doesn’t have a class definition for wglGraphicsStateGuardian for some reason, or
(3) Python doesn’t know the inheritance chain from GraphicsStateGuardian to wglGraphicsStateGuardian.
Actually, glancing at the code, I see that the problem is almost certainly (3). You’ll need to publish GLGraphicsStateGuardian as well, because that’s the intervening class. It needs to at least expose one method of that class for Python to see it.
We add parser-inc to the include file search path on the interrogate command line, so that when interrogate reads #include <windows.h>, it finds the file in parser-inc before it finds the one in the system.
If there is a name clash between different external libraries, then we have bigger problems, because the actual C++ code is going to experience the same name clash. Fortunately such name clashes are rare, but when they do occur, we have to take pains to isolate the parts of the code that use each conflicting name, so that no part of the code includes both clashing header files. This also solves the same problem with interrogate.
The parser-inc files serve two purposes. One, it defines the required typedefs or class definitions. Two, it shadows the actual header file, which interrogate is going to choke on anyway. If we had only one giant file, we would meet the first purpose, but not the second; so we need to have the individual files anyway. And therefore it makes sense to organize the typedefs into the appropriate files, instead of lumping them all (confusingly) together. Also, not all the C++ code includes all of the external library files at the same time.
You’ve got the right basic idea, though the ILIB name, by convention, should be the name of the directory, with lib prepended. So it should be libwgldisplay, not just libwgl.
The reason for IMOD and ILIB has to do with the way Panda is built on Linux and OSX, and how it is built (differently) on Windows. On the Unix-based platforms, a different .so file (similar to a .dll) is compiled for each directory, which is a good design that gives the most modular code. Each directory produces one “library”, which is named after the directory itself, with “lib” prepended, according to the Unix convention.
On Windows, this design doesn’t work, for various fiddly reasons having to do with poor design on Microsoft’s part for the dll format, so we instead have to compile all of the individual libraries together into a small handful of dll’s. These dll’s are called “metalibs” or sometimes “modules”. On Unix, the modules exist, but they’re just stub files that actually reference the individual library files. On Windows, the modules are the actual code, and the library files don’t exist. But interrogate (and makepanda) has to know about the modules and the libraries, and that’s the reason for the two parameters.
David