Мысли по ходу прочтения:
Если для относительно простых миграций это будут разные люди делать - то для большей части пропозалов миграций не будет вообще. Т.е. либо эту “отдельную” обязанность возьмёт на себя DWG (в чём я лично сомневаюсь на все 100%), либо на это сразу забьют.
Ну вот только что одну наблюдали.
Давайте пойдем от того, кому вообще выгодна миграция.
Выгодна она, прежде всего, авторам конвертеров и проектов по поиску/визуализации и т.п. - именно им удобнее, если нужно предусматривать меньше вариантов хранения одной и той же информации, если не нужно поддерживать старые схемы. Ради этого вопрос и затевается, на сколько я понимаю, а не ради абстрактного обновления и наведения порядка.
Так что нет, не забьют.
Возможность заменить что-то в базе - это просто более логичный вариант того, что и так делается в той или иной форме при втягивании данных в какой-либо конвертер. На это, как мы видим, не забивают. Разного рода валидаторы, ноги которых растут из конвертеров - из той же оперы.
Не забываем, что второй вариант уменьшения вариантов хранения - всячески гнобить новые схемы. :3
Что гораздо легче…
Я не отрицаю, что для некоторых douchebag-ов это может быть проще. Однако при наличии внятного механизма миграции это может стать менее актуальным даже для них. Если они не законченные douchebag-и, конечно.
Я за второй вариант, с например переходным периодом и оповещением.
Например мы везде где есть building entrance добавляем тег entrance yes - если это трактуется однозначно и например оповестив всех и вся, через месяц-два-три автоматически стираем нафег все building entrance. Этот вариант поможет более мягко подкачивать изменения софту и не губить работу всяческих программ, которые сами по себе ну не могут обновляться раз в неделю. Авторы тоже могут быть в отпуске/в декрете и т.п. 
Скорее уж через год-два 
вообще-то depricated это в первую очередь указание не для мапящих, а для кодящих. Чтобы знали, что есть метод лучше и включали поддержку нового.
А старые данные должны отмереть не в силу указа, а в силу невостребованности пользователями, ибо ведь есть метод лучше и его всемерная поддержка софта взамен ограниченной для сарого тега.
Про переходный период.
В смысле влияния на человеческий фактор, переходный период бесполезен. Предположим, что есть Вася с проектом показа POI. Он обрабатывает тэг key1. Для него переходный период означает только то, что key1 будет существовать несколько дольше. Если он пропустил каким-то образом оповещение о смене key1 на key2, сделанное за месяц до добавления key2, то само добавление также не будет для него “последним китайским предупреждением”, потому что key2 он просто в своем сервисе игнорирует, т.к. не знает о нем. И момент исчезновения key1 для него будет в той же степени неожиданным. Вопросы декретов и отпусков решаются до какой-то степени определением существенного срока оповещения. Но полностью предотвратить ситуации, связанные с человеческим фактором подобного рода, невозможно.
Единственное, что дает переходный период - время на контроль качества перехода проектов со старой схемы на новую (скажем, сравнение результата конвертирования с учетом старой и новой схем).
Хорошо, допустим для простых миграций можно пойти ещё дальше. Предположим, та же ситуация с entrance, т.е. машинно-однозначное расширение схемы без потенциальных потерь данных.
Делаем в несколько этапов:
В редакторах при наличии тега в списке устаревающих показывать ненавязчивую подсказку (жёлтым) с указанием урла-пропозала. При наличии тега в списке устаревших - вместо ненавязчивой подсказки показывать вполне себе навязчивый попап с всё тем же урлом и матами
Нет, переходный период нужен именно из-за человеческого фактора, т.к. нельзя заставить всех мапперов в одночасье прочитать, понять и начать использовать некий пропозал. Этот процесс будет естестенным образом размазан по времени, и если редактор в некий момент начнёт жёстко ругаться на какой-либо тег - многие мапперы либо проигнорят ругань, либо перестанут юзать этот тег вообще. Поэтому необходимо это сделать мягко, вначале ненавязчиво, потом жёстко.
Это вы сами придумали или вам кто рассказал?
Если мапер игнорит текущие предупреждения при выгрузке, то конечно он забъёт болт и на это. А так вменяемые должны разобраться в чём же дело.
GaM, http://forum.openstreetmap.org/viewtopic.php?pid=297494#p297494
тоже верно. ну а контроль качества можно проводить на n примерах преобразованные руками/ботом.
Все это здорово, а как же “any tag you like”?
Это я делаю выводы в первую очередь по себе, т.к. в подобной ситуации я открою урл, но совсем не обязательно буду его сразу же читать. Скорее всего замаплю по-старому если будет некогда/неохота читать, а когда дойдут руки прочитаю. Возможно даже перемаплю по новой схеме, а возможно и нет.
Не всегда есть время/возможность/желание. Да и вообще есть миллион всяких “но”. Тут все так любят брать в пример некоего абстрактного идеального сферического маппера в вакууме, что я вообще не понимаю, как при столь идеальных мапперах ломаются выверенные отношения (и не только в потлатче).
И уж тем более я не могу взять в толк как в одночасье внесутся изменения в рендереры, в шаблоны josm и потлатча и т.д. Имхо переходный период нужен.
Это в соответствии с этим принципом выпиливаются website=* и url=*? Имхо слишком много демократии - это плохо
Так что “any other tag you like”
а может лучше переходный период делать не в базе а на стороне рендерера, в шаблона josm и потлатча и т.д ?
хотя вариант множественных замен хорош, даже бота можно запустить еще пару раз после даты перехода, чтоб тем кто замапил по старой схеме не пришлось ручками переделывать на новый
В смысле сначала дождаться его поддержки в неких N-ныйх программах, а уже потом выпиливать ? Ну тогда собственно список должен прилогаться и иметься возможность пинать автора, чтобы не тормозил эволюцию.
Шаблоны редакторов всяко должны присутствовать в первом этапе перехода.
ErshKUS, ты вроде хотел сайт-редактор запилить для своего формата описания тегов.