This is something we’ve discussed a lot internally. As you’ve seen already, the current implementation does not work for names other than those of that “traditional” English format (I saw you used the phrase “Western”, but e.g. Icelandic and Spanish names behave differently).
My personal favourite resource on global naming conventions comes from the W3: personal names around the world. This refutes any global concept of “family name” or “given name”. I’d also add that Hugo (our Head of Design) is Spanish, so has a personal interest in this issue!
My opinion is that the best solution is two separate fields: “full legal name” and “what should we call you?” This serves additional purposes for us, for instance it allows us to refer to our Trans customers by the chosen name of their new gender identity, before they have made the corresponding legal change (the “legal” name is required for credit searches, etc.)
(As a side-note, “legal name” is actually a fairly nebulous concept in the UK – the Government’s change of name by deed poll page goes into this a little.)
We do keep a “preferred name” concept internally, which is why if you ask Customer Support to call you “Jim” instead of “James”, they’ll continue doing that in future interactions; but this concept is not reflected correctly within the app. As you have seen already, we have a long way to go.
Hopefully the above goes a little way to showing, firstly, that we intend to find a solution for naming that suits everyone, and secondly that any solution will require a great deal of nuance, given the large number of constraints: not merely on formatting of names and communicating with customers, but on the way we run credit checks, support name changes, and communicate with users whose “legal” name doesn’t represent their personal identity 
Great question!
Edit: I just wanted to add a clarification in response to the following point you made:
We ask for, and store, just the content of the “Full Legal Name” input field. Further uses are presentational only, and are derived from that field (not stored separately).
This was a conscious choice, for the reasons listed above: canonical data about names cannot make assumptions about concepts like “given name” that are not well-defined globally 
We’ve been thinking about names for a long time!