Sorry to revive the old topic again..
This is due to floating point precision and the iterative nature of the collision resolution solver. Changing the restitution to 0.98 makes the last circle act as if it has a restitution of 1.0.
IMHO his seems to be incorrect explanation, since it is gravity rather than collision resolver which is the culprit here.
e=1 behaves absolutely correct in absence of gravity, and almost no energy is gained even after thousands steps.
For the example attached in topic, my observations are..
The speed of body increases due to gravity even after collision with the ground for extra distance(penetration length), and collision resolver sets this speed after resolving collision, which leads to additional kinetic energy mge (where e is penetration length).
the gain in energy becomes unacceptable in case of polygonal small objects where penetration is high.
If this is for learning physics, you can, in the interface allow them to set the restitution to 1.0, but use 0.98 by supplying your own CoefficientMixer.
The solution can't work as penetration depends on speed and height which is variable thats why correction factor needed is also variable.
Is there any solution now? can we compensate for the extra gravity impulse in collision resolver?