When I was living in Japan I always had to "romanize" my Japanese address if I got something shipped from USA because USPS only allows ASCII. Even if this did create problems locally - post always arrive quicker (in my experience) if the address is in proper Japanese. When I got mail from my home country I got it forwarded via my company and they always just stuck on a printed label with my address, in Kanji. No problems there. Worked fine for years.

However, my home country postal system has since changed to an online system for sending post out of the country: You go to a website and enter the destination address, then you pay and it'll print a code which you just give to the actual post office when you bring the letter/package whatever. What's infuriating is that they don't allow Japanese addresses - I can enter it, but it just creates an error message. So I again have to come up with a crude romanized address and cross fingers that it'll arrive (which it usually does - but up to a few weeks delayed).

In short - things are not getting betters over the years.

The problem is that they were dealing with it successfully before, by either treating the umlaut as a "u" or a "ue". It's not like umlauts are this new technology that English speakers have never been faced with in their business ledgers. But what you see in older business ledgers, is a variety of different spellings, and a human brain that can map them to each other, with a little bit of training. And when software came along, most systems just used the "u" approach, and that kinda worked as software systems grew to massive scale.

Now the hard part is changing how to deal with it, because now you need to patch all these huge production systems that were working before, and it's a breaking change.

So if you have a big stack: UI --> business layer --> DB

You can't just change the UI, as that will cause breakage in the pieces below. You start with the DB change, then the business layer, and you do the UI last.

Moreover this is not a simple change. Getting a DB to handle unicode is a known thing, but how do you train your customer support personnel to do data entry with unicode characters? Do you expect the customer to remember the code point? There are many characters that look the same which have different code points. So what you need to do is come up with a list of officially supported extended character code points and do entry with those, but still you will have others -- users of Asian scripts, for example, whose characters will be missing.

And you will get customers still doing the old "u" approach together with the official umlaut code point, sometimes for the same name and the same package. People will call up, trying to find their package, and randomly used one convention, since even though you can train your staff (which isn't cheap) you can't train your customers. So you need some system of identifying different orthography for the same underlying name, some with "u" and some with "ü" and some with "ue". And then that's going to require changes in a lot of other systems, for example reporting systems, etc. We see this problem today, taken to the extreme, in the various different spellings of "Gadafi".

But really it's worse, as a distributed system has

UI <--> business layer <--> regional DB <--> business layer <--> regional UI

And now it's much harder to make these changes without taking systems off line, for a distributed global network.

What they probably did, as most companies do, is look at all these problems and costs, compare them to relatively small benefits, and kick the can down the road, waiting for the next major system upgrade, and sometimes these next major upgrades can take 20 years to happen. Or even longer.

In other words, the hart part is the incremental breaking change to the system, not the dealing with the umlaut. If this was a brand new code base that was just being written, they could make it handle umlaut with much less cost.