Rethinking the collision/separation system

Since there have been a few issues popping up with the collision system flixel uses (see #1301, #1270, #1078), and seeing how the next version of Flixel will be 4.0.0, this seems like the perfect time to rewrite the collision system. I would be glad to try my best in doing this after we have decided what the most optimal solution should be. Here's what I think now:

I think that the base of flixel shouldn't contain any separation logic whatsoever, only overlap checking. For that, I think integrating hxcollisions would be the best soulution. Haxepunk uses the same (or at least, it uses the same theorem), it's already well-written, and probably bug-free aswell. For the separation/physics, I think Phaser has an interesting, and maybe one of the best approach to this: they provide three different engine. One basic, something like flixel has now, one more advanced, with Circle hitboxes included, and one full-blown physics engine. Following this, we could have two different engines for flixel: one basic, something like we have now, and one with nape. For them to work with flixel, we could either provide an interface (hard to do, but more OOP, easier to integrate custom engines after), have different Flx classes (easier, but more classes, like FlxState and FlxNapeState, FlxSprite and FlxNapeSprite, what happens if we add a NapeSprite to a basic state?), or rewrite the classes so that their functionality depends on what engine is currently in use (so if you add an FlxSprite to a state, either an FlxBasicSprite, or an FlxNapeSprite gets added, depending on the engine the state uses). Nape integration is somewhat done, and the basic engine could use the same separation flixel has now, but it would have continuous collision detection (you wouldn't have to call FlxG.collide()), and masks. I personally like the third option, but the first could be manageable as well.

So what do you guys think?

The issue names no files or tests and remains an architectural proposal. Read the current collision entry point around FlxG.collide(), then compare the linked collision issues (#1301, #1270, #1078) and the mentioned hxcollisions, Phaser, and Nape approaches. Done would require an agreed engine and separation design before implementation.