If it were a build.settings thing, you could choose the correct options up front.
With setDefault() (not sure if this is what was meant), you would have to deal with setting it too late (after some physics has already been done, with the default; what do you do with the old stuff?), or setting it multiple times (same problem). These issues would also show up with different require() names , and I think it would be much easier to accidentally require("physics") in a module after already switching to version 3.
Gave the migration guide a quick look.
Just from seeing that I see that, despite the massive ABI overhaul, there are still common types, e.g. b2Vec2 is in both cases for Chains.
I looked over the engine source files that #include Box2D headers.
I think you could duplicate the Rtt_PhysicsSomething.cpp / .h files as Rtt_PhysicsSomething3.cpp, then replace the appropriate behaviors. This is probably essentially what you did anyway to add the version 3 behavior. Ditto for b2GLESDebugDraw and Rtt_DisplayObjectExtensions. There is at least some virtual interface in some of these already. (Particle systems might fit in here too.)
Rtt_Event.cpp's collision events need to handle either case, but maybe it’s localized enough that you could just do if (version1) {} else {} tests in those.
Rtt_LuaProxyVTable also has a few big switch statements for all the various Box2D properties. You’d probably also want another if / else thing there.
In these cases you would (without a bit of work… could elaborate if interested) be including the headers for both versions of Box2D. But then you’d be having duplicate names stomping on one another. Ideally you could #include version 3’s headers into a namespace and scope those names that way.
I saw that b2vec2 is also being used just as a handy vector type in some other spots. So we’d have to make sure those didn’t stomp on version 3, or get stomped on by it, either.
(Was just rattling these off skimming the search results in Visual Studio, but could link to various stuff too.)
