As far as I understand the technologies (and I assume that Berlin does the same thing as every other city-user), a precise ("physical") GPS position is usually not reported (although newer systems do that as well), but a position at a "logical" map is. In case of buses, this usually means "left the previous stop at $xx:$yy, with $zz seconds of delay; reported average speed is normal for this area, so expected arrival is at $aa:$bb." In case of trains, the usual reported data is "has left section of track $AA, is now at $BB, delay $x seconds, expected at $CC in $yy:$zz".
Not millisecond-perfect, but fairly precise to about a minute or two; the biggest guesstimate is the exact position (you'll see that all the trains seem to be using a single track, where in reality they would be on different ones).
So, while delays are reported near-realtime (and thus the scenario you describe doesn't happen), the map might be inaccurate if the route needs to be changed (e.g. there's an accident blocking the road and a bus needs to take the next street instead). Again, with the rollout of GPS-equipment across fleets, this becomes less of an issue.
Btw, most delays are unplanned ;)
My understanding is that with newer CBTC signalling systems--not sure if Berlin is using that--the trains know pretty much exactly where they are on the track, along with the positions of all other trains, speeds, braking distance, etc. This allows the trains to run closer together than they could using fixed block signalling technology. It's not required for full automation, but it makes full automation relatively simple.
The L train in New York is an example of where this is installed. My understanding is this means the two staff on the train are redundant; the driver pretty much just provides acknowledgement to the train to keep doing its thing, and the conductor only opens and closes doors and makes announcements (if that). They would run with only a single staff member except for union rules.
Oh, sure, there's all sorts of useful telemetry coming from the trains and the tracks, even with fixed-block signalling (unless you have a 100-year-old signalling infrastructure ;)). That's pretty much the case of most modern train systems: the driver is there essentially to (re)boot the train computers, push the "doors close" button, and for emergencies. Apart from that, the trains pretty much drive themselves (except when they don't, oh the joys of software).
However, even when the position of the train is known precisely (no need for fancy CTBC, just start counting wheel revolutions from a known starting point and reset any measuring error at the next known-good point, usually a station - which is the basic way the Parisians do it with their driverless metro lines), not every transport agency exposes this sort of raw data to the general public; usually it's watered down to "it's between Station A and Station B, with X seconds of delay."
As far as I'm aware, all the Berlin S-Bahn and U-Bahn lines use absolute block signalling.
FWIW, automation is actually mostly tangential to absolute v. moving block signalling. As far as I'm aware, most automated systems still use absolute block signalling.
It seems that often the signalling system and the real time location reporting system aren't integrated. In NYC on many lines you get reports like 'there's a Brooklyn-bound train 2 stops away' that they make over the loud-speakers. Makes me wonder whether they have a separate device that just picks up when trains pass by a track segment, rather than using the information available via the signalling.
In New York the signalling system on most lines is ancient. The L train has a CBTC signalling system and it has real time arrival information. The 1/2/3/ and 4/5/6 have had upgrades, though not to CBTC, to provide similar countdown clock functionality. The 7 train is undergoing work to install CBTC.
On other lines, my understanding is that the signalling system doesn't know which train occupies a block, just that a train occupies the block. Which block is occupied isn't sent to a central control center either.
So "there's a Brooklyn-bound train 2 stops away" is the best it can do, since it can know based on which side of the tracks the train is on where the train is going. It can't know the letter or number.
Well, that's one of the most archaic systems out there: http://gothamist.com/2015/07/28/subway_steampunk_video.php (Not the oldest, but using the oldest technology). If I understand it correctly, the only information available from the signalling system there is the rudimentary "there's something on this track segment now; it's up to the human controller to figure out what it is, where it came from and where it's headed."
As far as I understand the technologies (and I assume that Berlin does the same thing as every other city-user), a precise ("physical") GPS position is usually not reported (although newer systems do that as well), but a position at a "logical" map is. In case of buses, this usually means "left the previous stop at $xx:$yy, with $zz seconds of delay; reported average speed is normal for this area, so expected arrival is at $aa:$bb." In case of trains, the usual reported data is "has left section of track $AA, is now at $BB, delay $x seconds, expected at $CC in $yy:$zz".
Not millisecond-perfect, but fairly precise to about a minute or two; the biggest guesstimate is the exact position (you'll see that all the trains seem to be using a single track, where in reality they would be on different ones).
So, while delays are reported near-realtime (and thus the scenario you describe doesn't happen), the map might be inaccurate if the route needs to be changed (e.g. there's an accident blocking the road and a bus needs to take the next street instead). Again, with the rollout of GPS-equipment across fleets, this becomes less of an issue. Btw, most delays are unplanned ;)