If you have a detector rail it can affect rails directly connected to it. A powered rail for example is powered and a curved rail can change orientation. Imagine now to have a t-junction setup like in

The detector rail is on the left and passing it will cause the curved rail to change orientation. We start our cart not from the detector, but from where the rail is bend to. After starting the cart it goes into the bend and before leaving it, the detector will react. This causes a flicker in which the cart and the rail change orientation several times to then finally settle in the right-side position as in
This basically means the detector rail caused a change of orientation for the bend rail before the minecart was even standing on it.

I assume that the signaling goes by this: If the cart, would in a next step touch the detector rail, it fires. Since the rail is then bending in another direction there is an update as the minecart will now not go over the rail, causing another oriantation change. This then causes the detector to fire again going back to the situation in the beginning. The reason why this does not cause an endless loop is that each action takes one tick. Depending on the speed of the cart you will see a longer or shorter flicker then.

What I expected was that the cart will go to the left, not the right as it actually did.

Code analysis by pr0cess can be found in this comment.

James549:

• Fixed in 16w02a? Using the setup described in start.png, the minecart sometimes "bounces" off the rail and goes backwards.
• Half-fixed for 1.9.1-pre3.
  • Slow-moving minecarts will go the correct way, while fast moving minecarts will bounce back?!

Immaterialise:

• Confirmed for 1.9-pre1. It seems to be affected by the speed of the minecart as well. Fast and slow minecarts don't trigger it, but minecarts with a medium-ish speed do.