В каких стандартах (конкретные документы) описаны принципы нумерации версий, использующиеся в настоящее время на рынке ПО?

Я очень сомневаюсь, что есть какие-то стандарты. Каждый из производителей ПО сам себе режиссёр.

Тем не менее, существуют же устоявшиеся системы типа:
A.BB;
A.B.C build D;
A.B.C, где чётные B означают релизы, при этом C - это исправления ошибок, а нечётные B - развивающиеся версии, и C тогда отражает прогресс разработки.

Думается, хотя бы корпоративные стандарты должны быть.

Номер ревизии из svn как номер версии -- чем не вариант? Номера разные? Разные. Различаются? Да. Монотонно возрастают? Да. Можно определить по номеру, что за версия? Да. А что там номера сумасшедшие (например "версия 410") -- кого это волнует?

На самом деле волнует, потому что пользователю должна быть понятна нумерация, если первая поставка носила версию 410, а вторая 1234, а третья 1235 то это вводит дополнительную путаницу. Нумерация версий нужна пользователю. Нумерация билдов - поставщику. У нас в компании принята следующая нумерация х.х.хх. Первая позиция major version - это какая-то веха, вторая позиция отражает добавление новой функциональности, третья хотфиксы. Очень простая и запоминающаяся схема.

В Borland C++ Builder была система major.minor.release.build, при этом последняя цифра могла автоматически инкрементироваться при каждой сборке программы. Очень удобно.

Я для некоторых своих утилит применяю систему major.minor.date, гда дата записана как YYYDDMM одним числом, например 1.3.20080103. Дата удобна для отслеживания возраста программы/утилиты. Мне это оказалось полезно в проекте, где в сервисном режиме применяется кучка вспомогательных утилит, и просто номер версии 1.3 ничего не говорит о совместимости утилит друг с другом.

Посмотрите нумерацию версий ядра linux. Как вариант можете рассмотреть и наименование архивов с исходными текстами ядра.