round(2.5) даёт 2, и ученики не верят

Ответ на «зачем» - это подсчёт. Сложите четыре ничьи точно, получится 8. Округлите сначала половины вверх, получится 1 + 2 + 3 + 4 = 10. Округлите к чётному, получится 0 + 2 + 2 + 4 = 8. Округление вверх толкает каждую ничью в одну сторону, и ошибка растёт с числом ничьих. К чётному отправляет половину в каждую сторону, и в среднем всё гасится. Ученик, который переходит между языками, встретит оба варианта, ведь math.Round в Go округляет половины от нуля, а math.RoundToEven - отдельная функция.

Одну вещь, мне кажется, стоит держать отдельно от этого урока. round(2.675, 2) в Python даёт 2.67, и ученики относят это к тому же сюрпризу, но причина другая. Ближайшее к 2.675 число с плавающей точкой лежит чуть ниже, так что никакой ничьей нет вовсе, и документация Python приводит ровно этот пример. Поэтому сначала ничьи, на значениях, точных в двоичной записи, вроде 0.5 и 2.5, а представление чисел вторым шагом.

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

Первая строка показывает хранимое значение, 2.67499999999999982236431605997495353221893310546875. Вторая даёт 2.68, потому что строка сохраняет то десятичное значение, которое ученик действительно набрал.

Добавьте в список базу данных, она не согласна сама с собой. В PostgreSQL round(2.5) для numeric даёт 3, а для double precision правило для ничьих зависит от платформы, и round(2.5::float8) обычно даёт 2.

round(-0.5) в Python даёт целое 0, а round(-0.5, 0) и round(-0.5) в Julia дают -0.0. Никто этого не замечает, пока Julia не поделит на него и не вернёт -Inf.