Let me explain what is happening here, since it's not intuitive, but also very unlikely to be changed:
Inserters perform rather expensive calculations which is why the results of many of those are saved rather then recomputed every time they're needed. Two of these results are the entity an inserter is going to pickup from and the entity that the inserter is going to drop his items onto/into. Once it saved those, it'll only perform the much less costly check of whether or not it is able to still interact with them (e.g. they could be deconstructed, or moved away too far in case of cars).
The other thing to know is what happens when one of those two saved entities isn't valid anymore, e.g. how the inserter searches for a new entity. It's not surprising that it looks which entities are in range of it's pickup/ dropoff spot, but what may be surprising is how the inserter decides when multiple entities are possible:
- In case of both a car and a belt being in range at the dropoff, the inserter will always prefer the car.
- In case of both a car and a belt being in range at the pickup, the inserter will always prefer the belt.
This explains the behaviour you're seeing, since even if the car is already stopped at the correct position, the right inserter will always bind to the belt instead and completely ignore cars.
Another thing to note is that once you move the car away and give the left inserter any reason to start his swing (and thus decide to insert onto the belt), it'll get similarly stuck on the belt and ignore cars for all eternity.
The workaround for this problem is to drop/pickup from the tile beside the belt (either orientation usually works) and exploit the nice and large hitbox size of car, as seen in the reply by disentius. The inserters will never have the chance to break since they can't "focus" on the belts. You can also run the risky business of inserting onto a car belt directly, by making sure to circuit-deactive the inserter at all times that no car is present, but that is far from easy.
Note that this behaviour will very likely never change due to performance reasons: it's really expensive for the inserter to search for a car in range (or any entity for that matter), and the only way for this to work "correctly" is for the inserter to do that search every single tick - not only is each search expensive, but it would also prevent the inserter from ever sleeping, which is an extra hit to performance. Considering that inserters are regarded as the current enemy no. 1 of UPS by many mega base builders (and the Devs likely know that), we're very safe to assume that this behaviour will not change.