Where I live, a majority of residents speak English as a second language if at all, but all the streets are named exclusively in English. When a Spanish speaker gives directions to turn onto North 4th Street, they may call it calle cuatro in translation or nort fort estret in Spanglish. A Vietnamese speaker won’t flinch at Google Maps calling it nót phót xtrít in Vietrish or Apple Maps calling it đường số bốn in translation.
A decade ago, it was still somewhat rare for a text-to-speech engine to be able to handle embedded foreign-language text, especially without any indication of the language. Today, that capability is quite widespread, even among existing OSM data consumers. For example, the Mapbox Navigation SDK uses Amazon Polly, which has no problem embedding Spanish inside English. If you prefer code switching, then you can mark up the text as a particular language using SSML. In this English recording, the street name “Calle 8” is marked up as Spanish, so it comes out as calle ocho instead of callee eight. This is no longer strictly necessary for common language pairs like English–Spanish, but more distant or obscure language pairs such as English–Chinese or English–Haida could benefit.
I understand that your proposal is designed to make it easier to come up with the language code to mark up the street name. You’re right that a semicolon delimiter doesn’t solve this problem generally. However, your proposal still needs to account for the possibility of multiple names in the same tag, because that can happen even within a single language:
Your proposal takes some pressure off disparate local communities so that they no longer need to try so hard to coexist in name=*, but it doesn’t solve the problem that semicolons are intended to solve. On the bright side, you’re using semicolons to separate language codes. 
I’m not entirely sure where this is coming from. My suggestion in this thread was to introduce a semicolon delimiter as an option where name=* is already set to multiple values. If any government policy causes widespread changes on the ground, then OSM probably should see widespread changes. That goes for languages, currencies, speed limits, access restrictions, parking rules, addressing schemes, flags, you name it.
I think this is a difference in expectations. A variety of renderers, representing a variety of tech stacks, as well as non-renderers, have been handling delimiters in name=* for years without any fuss. After all, it’s just a little bit of string manipulation. Granted, not all renderers do this. I don’t know how realistic it is to expect “all” renderers to implement your proposal either.