I absolutely agree it suffers from multiple flaws in its current state (even it’s own wiki says so!). That’s why said “improve on solution like default_language=* / language_format=*” and not “use it verbatim in its current state”. For starters it should have clearly delineated variables (e.g. something more along the lines “${name:hr} - ${name:sr-Latn}”)
Some are easily fixable by having better syntax, some has already handled counterparts (e.g. coastlines), and some are inherent but handleable (e.g. Antwerp extract would either have to duplicate default_language for itself, or have extract generator add it automatically, or store it separately somewhere or simply have user defining its own preferred rendering which maybe be same or different than “official” one) and some are actually easier to use then alternatives (e.g. vandalism case requires fixing just one tag, instead of many thousands of potentially modified objects for which clean revert is problematic in case if user just blatantly replaced multiple name tags and those objects changed afterwards).
None of those problems seem insurmountable to me; but yes, they would need extra discussion if people are interested in such more versatile solution, which is why I suggested it for consideration (if noone is interested, I certainly do not intend to start one-man crusade war over it 
)
- What to do when one of the referenced keys is missing?
Whatever we want, eh? Simplest solution “just substitute null string” is admittedly not very nice, but even some basic handling (remove trailing fixed chars before null variable) produces much nicer results. Or if needed one can go more advanced ways if needed (e.g. posix shell variable expansion, ternary conditional operator, etc.) or even hardcode some rules. But I’d personally prefer to keep it somewhat simple.
- OSM XML doesn’t support newlines in tag values, but what if a newline is the best delimiter?
The same as you would do in name=* case - you’d have to represent it somehow (common syntax is usually ASCII sequence \n, but one could use UTF8 shenanigans instead). But it would be much simpler to add it once by few experienced users in more powerful/customizable editor for the whole country/locality, then to depend on zillions of users on the ground with their different apps to all support it correctly and have all those zillions of users educated to use it correctly to map every single name.
- What should
default_language be when the delimiter isn’t inherent to all the features contained within the boundary but rather depends on the map designer’s stylistic preference? (Do we agree that this is a legitimate opinion for a designer to have?)
Absolutely, in fact giving that freedom to map designers is one the my main goals behind that idea (and even more extended than that - I think every user should have possibility to become simple map designer by tweaking rendering profile to their needs if they so choose. Sure majority want, but they should be able to). So, instead of having name=aaa / bbb that some random mapper on the ground has chosen as “best” and having map designer be at their mercy, the map designer would be one with power to choose what to render. They could take that default_language and use it verbatim (e.g. similar to current osm.org map), or they may decide to replace that “-” inside default_language (or “/” or “;” …) and replace it with newline or a picture of a red star or whatever. Or they might extend provided default_language with a newline and int_name. Or they may decide to disregard default_language altogether and render names for whole world in Croatian only (or whatever). Or they can have simple (or complex) set of user preferences they want to follow depending on the users will. IOW, map designers should be able to decide whatever they feel best for their specific use case!
Why not acknowledge the reality that name has multiple values in it?
I do acknowledge it is the reality (what I do not particularly accept is the claim that we should encourage the users to do more of it, instead of less of it). In fact, that reality is actually one of the main reasons I think it very uphill battle trying to convince every mapper in the world to map names in some specific way. It would IMHO be much simpler (and more realistically doable) to hand-craft and curate few hundreds (or thousands) default_language tags, then to try to handle every single name=* tag in existence and their additions/changes (even with such effort supplemented by very good AI bots).
If default_language is such a good idea, it can contain a semicolon too.
Sure, it can, if some locality really likes such separation of names with literal semicolon “;” characters (hey, I’m not judging!)
My experience is somewhat different about that “effectively”. Sure, it is possible to support them, and some have done it (to some extent at least), but majority I’ve seen do not seem to really handle them (and even more importantly, is it often impossible to even define them that way in ideal or even useful way, even with all goodwill of data consumers at disposal, as mentioned before with sidewalk example). (Additionally, parsing it sucks at efficiency - if I want to find every element that offers Croatian cuisine, I have to do extremely inefficient fulltext search on cuisine=* tags to find results containing croatian substring – if it were instead tagged as cuisine:croatian=yes, it would be very fast indexed find).
)