@stupidname, those are good arguments. But I have counterarguments.
The field was originally named “Country”, with a data structure that accepted only Country values. But then it was changed to a structure that accepted any Area value, and it was renamed to “Area”, and there was no style guideline which said “We only mean for this to hold Country values”. Quite the contrary, there is a style guideline which says City values are preferreed sometimes. I argue that the field’s meaning has already changed, to be quite broad. I’m just proposing to change the emphasis within that broad range. This doesn’t invalidate existing data.
“We need a field for some kind of nationality.” Fair enough. But I’d argue that Artist.Area doesn’t store “nationality”. According to the current guidelines, it usually stores “place of birth or origin”. Nationality can change during an Artist’s lifetime. Maybe we should have an Area-Artist relationship “Nationality”?
I’ll observe that “Taylor Swift lives in New York" is a claim about residence, “Taylor Swift is American” is a claim about nationality or legal status. I argue that Artist.Area should be a claim about “is mostly associated with”. These are three different claims. It would be good for us to be more clear about which claim Artist.Area makes.
You are right that a single field can’t represent multiple values for nationality, or residence, or “is mostly associated with”, especially as they change over time. For that, relationships are a better data structure. Ticket MBS-9155, Replace artist and label areas with relationships proposes this change.
Update: clarified wording.