round(2.5) gives 2, and learners don't believe it

The why is a count. Sum the four ties exactly and you get 8. Round every tie up first and you get 1 + 2 + 3 + 4 = 10. Round ties to even and you get 0 + 2 + 2 + 4 = 8. Rounding up pushes every tie the same way, so the error grows with the number of ties. To even sends as many down as up, and on average it cancels. A learner moving between languages will hit both, since Go's math.Round rounds ties away from zero and math.RoundToEven is the separate function.

One thing to keep apart from this lesson, I think. round(2.675, 2) gives 2.67 in Python, and learners file it under the same surprise, but it has a different cause. The float closest to 2.675 sits a little below it, so there's no tie to break at all, and the Python docs use this very example. So ties first, with values that are exact in binary such as 0.5 and 2.5, and representation as a second step.

from decimal import Decimal, ROUND_HALF_UP
print(Decimal(2.675))
print(Decimal('2.675').quantize(Decimal('0.01'), rounding=ROUND_HALF_UP))

The first line shows the stored value, 2.67499999999999982236431605997495353221893310546875. The second gives 2.68, because a string keeps the decimal value the learner actually typed.

Add the database, since it disagrees with itself. In PostgreSQL round(2.5) on numeric gives 3, while double precision ties are platform dependent and round(2.5::float8) usually gives 2.

Python's round(-0.5) gives the int 0, while round(-0.5, 0) and Julia's round(-0.5) give -0.0. Nobody notices until Julia divides by it and hands back -Inf.