Minko physics is probably one of the most awaited features for this new year. I will not cover it extensively right now - I'll rather post a few demos in a later post - but if you must know it was designed to be the fastest 3D physics engine for ActionScript 3 and the Flash platform.
I will share extensive details about this new physics engine during the Stage3D online conference in February. Make sure you attend: it's online and it's free! 
The Demo
Anyway, I just wanted to tease the community with one of the stress tests we're using here to benchmark the engine. It's a really simple test and it uses only a very very small subset of the available features.
Here you go (just press "space" to throw some balls):
About Scalability
There are actually quite a few interactive objects active at once in this scene: more than 350! And if you throw some balls (using "space"), it should go even higher. Yet the application should run very smoothly on a decent computer: the framerate doesn't get below 24 fps on my 2011 laptop using a core i7@1.5Ghz/Intel HD 3000.
The number of contact points/collisions and therefore the stacking appears to be the main bottleneck here. And that's a very good thing since it's precisely the point of this stress test.
When the application starts, you might also notice that the framerate doesn't reach 60 fps until a few seconds. This is because colliders need this time to stabilize and "fall asleep" when they finally stop moving for long enough. After a few seconds, you should get 60 fps. If you don't, it means your GPU is the bottleneck since sleeping physics colliders are actually virtually free. This also means the engine can easily handle very large physical worlds and detect/compute collisions in a very optimized fashion.
Future Improvements
You might think that the fact we're using boxes might makes things a lot faster for the physics engine. Yet we've implemented nothing special for boxes collisions tests so this is a real glimpse at the actual general performances of the engine. Other stress tests will enlight that of course, and we might implement box/box optimization in the future to get even more performances.
When you press space to throw a ball, you might also notice a performance drop. This is unlikely to have anything to do with physics. I think it's rather related to the fact that adding new scene nodes will require to rebuild the local to world transforms tree into a linearized list. This might be avoided by re-using the "fallen" balls instead of building new ones everytime "space" is pressed.
Of course, feel free to discuss this demo and share your results in the comments or on Answers.