Yeah, I think apps just should have a sorted list (/tiers) of languages they support, and pick whatever first has a match in the user preferences. If the app supports two languages equally well, then choose the one first in the user's preference list.
So for me having no,en (in the future where this works I would dare to have no first):
app is in english, has auto translated norwegian: choose english
app is in norwegian, has auto translated english: choose norwegian
app is in norwegian and english equally: choose norwegian
app is in french, has english translation: choose english
People figured this out when they specified HTTP 1.1 in 1997. A prioritized list of the languages the user knows. They even allow a q-factor weighing so the user can specify a factor of how comfortable they are with a language. All modern browsers already support this, but 99% of websites fail to use it properly including Google.
It's like modern apps have forgotten all lessons learned about internationalization.
Same in Windows. The "modern" system apps use just one setting (Windows language) for internationalization, ignoring the old date format and time format settings. So if I set my Windows language to English, I get AM/PM and dot as decimal separator in some parts of the UI and not in others.
Google is notorious for ignoring browser language preferences not only in Youtube but also in its main product, and inferring from the (often faulty) geolocation.
So for me having no,en (in the future where this works I would dare to have no first):