Hey! Good list. It's always good to get some feedback.
1) While you can't change the memory handling functions at runtime, you can configure it to use something different at compile time. That is where the defines for cpcalloc(), cprealloc(), and cpfree() are located. It makes it pretty trivial to make Chipmunk work with the Boehm GC or work with memory allocated by language bindings for instance. I've tried to make sure that I don't rely on cpcalloc() to zero the memory anymore, but it's not well tested. Most Chipmunk memory can be allocated and freed externally too. Instead of using new/free (or the rare alloc), you use init/destroy instead on externally managed memory. Only internal structs like arbiters, arrays and buffers would me managed by Chipmunk then. Does that make more sense? It's not really documented. I assumed the few people that wanted to know would just end up finding it. (great documentation strategy huh?)
2) So this is perhaps misunderstanding on my part, but what is the problem with this? Divide by zero to get infinity is in the spec and pretty handy. With most ABIs, it's even invalid to turn FP exceptions on (unless you turn them back off before making system calls). This came up too. Near as I can tell, all modern CPUs with an FPU (ARM, x86 with SSE, PPC, etc) seem to handle "exceptional" math with infinities and subnormals without a performance hit.
3) Actually, this came up recently (can't find the thread...). I have it on my TODO list to allow for compile time re-definition of the fast collision filtering. Basically you'd just need to give it a struct and a short inline function. In the past, I didn't really get why it was useful to have separate mask/category bits. They encode more or less the same information except redundantly, and let you set up contradictory rules. A could say that it collides with B, and B could say that it doesn't, so what would happen? Anyway, ODE uses the same rules and I looked up the explanation in their docs a couple months ago. Basically it said just that, you could encode the same information into a single bitmask, but it's not as easy or clear. It also lets you say objects of the same type don't collide, one thing you can't do with a single bitmask. ODE let you handle the contradiction yourself which makes sense, Box2D did not which always confused me. Anyway... long explanation.
Per-body properties: I've thought about adding a number of per-body attributes like that. Just haven't gotten around to it mostly. You can do it yourself by defining custom integration functions, but the documentation for those currently just says to look at the Planet demo. <_< Doing so isn't always convenient either.
4) This actually drives me nuts... It was a mistake I made very early on with Chipmunk because I started with a bunch of the polygon collision code I had before Chipmunk. It didn't really occur to me that it was "backwards" from the way that regular math-ish stuff works until other people had already been using the code for a while. I'm getting a little tired of adding negatives into just about every piece of code I write that deals with polygons.
Now that you bring it up, it makes me think I should make a compile time define to pick the winding direction and deprecate the current direction. Will put it on the TODO list to think more about.
5) I recently fixed a really boneheaded bug in cpvslerp() too. -_- Basically I had never tested it with non-normalized vectors, and had only used it once or twice anyway. Oops. The regular trick for handling very small angular differences is to lerp them yeah (the curve is so small it's pretty much linear anyway). I'll put that on the TODO list too.
Awesome looking game so far.
Reminds me of a 2D version of Max Payne (except without the ).