1,3 - плохие. Вернее, нерабочие. Фактически, от 2-го пункта отличаются лишь еще одним геморроем - кто и как будет следить за сквозной нумерацией X в housenumberX? Проще тогда уж ставить вместо X кладрокод, он хоть уникальный. 4 - вообще ни в какие ворота не лезет и однозначно такого не должно быть.
Остается 2, без вариантов.
Рано еще голосовать.
+1, я сразу не учел этот момент. Но все-таки к 1-й схеме он не относится.
Таки еще раз напишу свой вариант: каждая улица - одно отношение, имя роли равно номеру дома (или включает его).
Адрес может относиться к любому количеству улиц (микрорайонов, кварталов и т.п.), дополнительных отношений не требуется вообще.
Не нужно заморачиваться с основным и второстепенным адресами (каждый из которых требует “лишего” отношения), редактировать любой адрес можно независимо.
А если требуется, скажем, задать несколько вариантов написания одного адреса?
Например, “4 корпус 1”, “4” (корпус часто опускается), “4к1” и “4-1” (Аналоги name, alt-name и т. п.)?
Тут согласен, имя роли как поле под номер ровно одно. При использовании дополнительных отношений разнообразие больше.
Встряну 
Смысл есть в том, чтобы, например, не использовать для описания сущностей неуместные названия. Лучше дать определение некому абстрактному уровню N и оперировать им уже с оглядкой на это определение. Кроме того, это определение можно выбирать так, чтобы с получившейся адресной иерархией было удобно работать. Например, если подгонять её под административно-территориальное деление России, то семантика слова “город” (или “city”) будет мешать различению таких городов, как Москва и Нижний Новгород. Ну а нумеровать уровни нужно чтобы на практике адресной иерархией было легко пользоваться.
Вот именно, всё уже перенумеровано до нас
Я тоже сначала так хотел, а потом склонился к Лешиному варианту. Его вариант (одно отношение на второй адрес) дает возможнось обработать понятие Главный, основной адрес.
Впрочем, и в варианте ‘штаны’ (по отношению на каждый адрес) всё равно наверно можно догориться, как обозначать Основной адрес. В этом случае на контуре дома мы пишем только физ.характеристики - этажность и прочее, общее к обоим адресам.
И отдельная мысль: каждый way должен входить только в единственное отношение street, иначе рендер не поймет, какое название улицы на нем писать.
Если эти коды есть в какой-то стандартной нумерации, то пусть будут. Тогда другое дело, зачем писать address:a3= вместо просто address=? Для сборки адреса это будет не помогать, а только мешать. Более того, написание address:a3 потребует обязательного указания address:type, и соответственно, необходимого выяснения, к какому уровню той классификации адрес относится (а это дополнительная ненужная работа для маппера).
Как именно номера облегчают использование адресной иерархии?
А если его нет или неизвестно, какой основной? Вот рядом с моим домом стоит дом 42 по Ивана Франко / 2 по Боженко. Что куда я должен совать? А если я решу, что 2 — это основной, а окажется что 42 — я должен все отношения перекорёживать?
Основной адрес должен быть на самом доме, хотя бы потому, чтобы его могли узнать те, кто не в курсе вашей адресной схемы.
Но вместо вопросика, ведь, что-то нужно подставить? И a3 в качестве значения будет удобнее и в некоторых случаях правильнее в плане организации поиска, чем city.
А вот это я не понял, зачем, когда эта информация уже ассоциирована с address:a3?
Не номера сами по себе, а фиксированность в некоторых пределах этой иерархии облегчает её последующее использование. Например, адреса можно класть в соответствующим образом денормализованную для быстрого выполнения поисковых запросов БД.
Или, по-другому, зная идентификатор объекта вы в любом случае сможете восстановит его адрес. Но чтобы по адресу легко найти объект нужно соглашение о том, как этот адрес должен выглядеть.
Вместо вопросика в этом предложении не надо ничего подставлять, это знак вопроса, обозначающий, что предложение вопросительное.
Ты, наверное, не понял, что я имею в виду.
В схеме предлагается использовать тег address:а3=Кубинка. Мне совершенно непонятно, что мешает написать просто address=Кубинка, всё равно разные части адреса не будут встречаться в одном отношении.
Замечу попутно, что заявленная схема обозначения элементов адреса не совпадает со схемой иерархии адресов. Например, есть два таких элемента:
a6 и sts,
где a6 — это собственное улицы без родового (например, «Ельнинская»), а sts — родовое (street suffix, например, «улица»).
Понятно, что на уровне иерархии улиц, должны быть и то, и другое, причём одной строкой, потому что «Ельнинская улица», но «улица Ивана Франко».
При этом белорусская схема в данном случае не соответствует стандарту, т. к. помещает в a6 и то, и другое вместе.
А ещё отсутствует оное деление на уровне населённых пунктов, поэтому как кодировать «посёлок Мисцево» и «деревня Мисцево» (находящиеся в одном районе) совершенно неясно.
Ничего не мешает, но избыточность добавит наглядности и поможет легче отыскивать ошибки.
Кстати, можно было бы, в данном случае, не использовать тег address и не писать =Кубинка, а добавлять соответствующий полигон границы в отношение.
Как показано в моём последнем посте выше, это не только не добавляет нашлядности, но ещё и запутывает.
Если хочется иметь фрагменты названия в соответствии с RFC4119, то можно ввести address:a3 и т. д. в качестве дополнения, но не основного способа сборки адреса.
Использование названия местности — интересная альтарнатива. Если оно совпадает с точным элементом адреса — почему бы и нет? Только вот иногда это населённый пункт (с контуром, который предлагается вносить в какой роли?), иногда улица или площадь (маленький клочок посередине, с ролью street; нужна ли вообще отдельная роль для улиц?)
Основной способ - не address:a3, а просто name, и не надо всех пугать 
Ну нету в моей схеме housenumber, housenumber2, housenumber3… Нету! Читать надо не через строчку и не домысливать.
Варианты указания тега номера строения существуют для работы двух-трех параллельных, одновременных адресаций. У нас каждый дом имеет два адреса, а некоторые и по три.
вопрос 4, кста, относится ко всем схемам…