This is all good stuff. I think the ten-million-dollar question, still to be answered, is whether the swig-generated code runs faster or slower than the interrogate-generated code, especially the new version of interrogate that we have in-house and will make available soon.
Build time is important for developers, and the prospect of a much faster build time is exciting. Although I think the currently very large runtime for interrogate is indicative of some bug: it didn’t used to take so long, or so much memory; and surely that bug can be fixed.
I think the most important thing to be gained from a switch to swig would be the adoption of a well-maintained tool (well-maintained by someone else 
). But that does cut both ways, too, because that means someone needs to maintain the interface to swig, as both swig and Panda continue to grow.
There are still a few stumbling blocks to overcome before we can even consider wholeheartedly embracing swig. The biggest is the large body of code that is already written using the interrogate-generated interface; we would probably need to find a way to finesse the swig interface into being mostly compatible with the interrogate interface. The first 90% of this is renaming the methods the same way we do, which is trivial; but the rest of it may be trickier (automatic reference count maintenance?).
David