Order is correct. Script used is Cyril but actual order is an Latin alphabet. If Cyril alphabet is used, that would be real nightmare.
About other namespaces of addr tag: there is again serious database design flawz. There are addr:street, addr:city and addr:country keys which are all redundant. street, city and country are already defined. Those keys should not contain redundant data but point to objects that are already defined in a map. those objects already have name tags that are set properly and in multilanguage manner.
No, it is not a problem. House numbers can be easily transliterated to Latin or Cyril script for search purpose, as there are used only those letters that are common for Latin and Cyril script.
The only problem are addr:street, addr:city and addr:country which contain originaly Cyril contents and which is not easy to transliterate to Latin for search functionality.
This is, actually, database design flaw. Tag addr:street is redundant as there is already name:* which contain necessary data. All problems are raised from that redundancy. Redundancy has to be solved. The best solution is to remove addr:street tag as unnecessary or make ot point to exact object that represents street. It’s contents as it is defined now is just an unnecessary duplicate of already existing information.
You are suggesting that OSM database should be fixed in manner that suits some rendering needs. This is wrong. Main principle of OSM database is to contain data not fixed for rendering needs. What you see as rendering need is not unique and someone else has different needs.
And rendering need you see is actually wrong as transliterating Cyril to Latin contents for search purpose is not as simple as you think. I dealt with that issue for years. Search will not work good if you just transliterate. Check www.vokabular.org. There, we dealt with this problem and achieved search on Cyril contents of a database to work regardless user uses Cyril or Latin search keys. We did use transliterated form of database contents but it was not simple Cyril to Latin transliteration.
This is not problem just with Serbian language and Cyrillic. This is problem with any language that uses letter other than plain English Latin script. Map user does not necessarily have to know language used for addresses, and especially does not have to be able to use keyboard that offers entering characters specific for given language.
To make things worse. OSM designers decided to allow primary usage of languages of minority, so we do not even have consistency in naming scheme, and, as things are now, we all have to know all languages and have keyboards for all their alphabets used to be able to use map of Serbia, including searching. And that is all for map of our own country! What about foreigners? What if we go abroad, in some exotic country. This is all ridiculous per se.
The only solution for this problem is to allow full multilanguage use of database. That means addr:street has to allow multilanguage contents in the same manner as it is done for name tag. That means any tag that allows custom entered text has to be multilingual.
Unfortunaltely for OSM database designer, multilinguality is not just allowing unicode in name tag. It means that all functions have to work as multilingual.
