I'd say with your second patch, it does indeed work.
Now, you say we might have a bug in our initialization, and that might be true, because we had to jump throw hoops since we create rigid bodies without collision shapes, and add the shape afterwards. Looking back at our code, we couldn't find the culprit, but we are aware of another bug where a collision shape is sometimes ignored (haven't isolated that one yet, but it does indicate we do have a bug somewhere). What we can say is that we recompute the inertia tensor when we do assign the collision shape to the body, and if that code didn't work properly, our sphere wouldn't be rolling like it is now.
OK, so back to your patch.
It does get rid of contact stability issues of boxes on the floor, but it sounds like stacking is now a little less stable (a wall of boxes take less time to fall when we have no deactivation). Also, it sounds like stacked boxes now shake a little more; it's subtle, but once in a while, you'll see a box pop up slightly more than the previous code ever did. It's as if some energy would pile up, reach a threshold value, kill the contact and transform into a collision, then fall again and get back to contact the next frame. Just a theory for now, though.
Also, our rolling ball now has a peculiar behavior... When it has a slow speed, it will sometimes hit something, deflect, roll away, but then magically come back to the recently hit object. This behavior is worst than being simply sticky: the ball actually backtracks to apparently re-enable a contact that, I think, should have disappeared. Similarly, when the ball rolls near a static obstacle, it will sometimes get pulled and change its trajectory before actually hitting the obstacle. I wonder if it could be related to the removed m_restingContactRestitutionThreshold variable that was removed.