Steps to reproduce

1. Place a sticky piston facing a chunk border, so that it will extend across the chunk border.
2. Attach a clock circuit to the sticky piston, and place a block on its face so that it pushes the block back and force.
3. After a period of time, force-close or crash the game.

Expected result

The setup is as you left it.

Actual result

The setup sometimes breaks, with a standalone moving block that is not moved by the sticky piston, or the piston head overlapping the block it was pushing, or the piston stuck and unable to extend into seemingly empty space where a wireframe show when you point at the piston as in the thumbnail below.

This is an incredibly strange bug, knowing how chunk data is stored within the game.

Long story short, I have a world containing a fully automatic chicken farm, using what is known as an Ethos Hopper Clock, which is a form of redstone clock that uses items moving between two hoppers as precise timing, a redstone block on top to power one of the two hoppers, observers on the sides, and pistons to push the redstone block side to side to create an update for an observer block to use to power an output.
Now, the bug.
Somehow, and I have no idea how this happened as I noticed it after my chicken farm stopped producing food for a while, the piston arm, and the redstone block used in the design, ended up occupying the exact same space. Neither the piston arm, nor the block, were in their moving block entity form, and were fully solid, interactive blocks. This seems to be a rare bug, and I can only theorize it to have been caused by the chunk unloading at the very moment the piston began moving, either by quitting the world and reopening it, or by traveling away and unloading the chunk via simulation distance. 
This bug may be very difficult to reproduce as a result of the incredibly precise timing in my theory, but if any other method is found, hopefully it'll be fixable, as I can imagine this could potentially break many sensitive redstone designs that require precise timings.

In the screenshot provided, you can see that the piston is in it's extended state, with the redstone block directly in front of it. I had to time my screenshot so that the Z-Fighting of the piston arm and the redstone block could be seen, to confirm the piston arm wasn't simply overwritten by the redstone block. It should also be noted that breaking the block that's occupying the space that the arm is in will result in the piston being completely deleted, not even dropping as an item, futher confirming that neither block was in it's moving entity state.