This is easy to reproduce, you don't even have to start-up a plane: Start FG with the Super Constellation, place it at the beginning of a runway, switch to an outside view, and look where the plane is located in relation to the runway markings. Then start the replay mode, and stop it again. The plane will be shifted by almost half its length in a forward direction, and it also seems to drop a little bit, because it has been lifted slightly. This phenomenon is plane-dependent, e.g. the DC-3 seems less affected than the L 1049H, but it can lead to the tail being pushed up and the plane ending up on its nose. I've tested this with two Yasim planes too, and they don't seem to be affected at all. But this could be a coincidence with the planes I chose (B-17 and R44).
I've noticed this long ago, but I've never looked at it in detail, although it can be a little annoying when using my way to restart from a previous flight, and obviously it is irrelevant and won't even be noticed if you replay during flight.
But now I noticed that the space ship I'm modelling is severely affected by this: After stopping the replay, it is pressed into the ground by about 10.4 metres! The distance and direction of movement led me to the probable cause of the error rather quickly: 10.4 metres is the vertical distance between the JSBSim coordinate origin and the centre of gravity (my ship is rather high, even compared to an A380, and the coordinate origin is at the bottom). Both points are exactly on the z axis, and that's why the ship doesn't move to the front or back when stopping replay, only down.
Looking at the L 1049H, we will see that the coordinate origin is at the nose, while the CoG should be somewhere between the wings. The difference of 681.6 inches is the distance the plane is moved forward, and the small difference in z position of coordinate origin and CoG (only -34.1 inches, compared to +410 inches in my space ship) causes the slight upward movement followed by the drop.
So what is happening? During replay, some of the properties have obviously to be saved somewhere, and when ending replay mode, they are written back into the property tree. Either during saving or restoring, something gets mixed up. It looks as if the CoG is placed at the saved position of the coordinate origin, causing the forward and upward movement of the L 1049H and the downward movement of my Python. In this context it may be interesting that the property "position/altitude-agl-ft" refers to the CoG, while the property "position/altitude-ft" refers to the coordinate origin. This probably has a good reason, but it looks like a bug waiting to happen, and it could be somehow involved with the repositioning bug.
If anybody can reproduce this, I'll try to get it to the bug tracker.