Last time, we looked at the evolution of the control panel settings which control the language groups for which Windows will install fonts, code page information, and other support collateral. This was in the context of a customer who was trying to migrate from Windows 2000 to Windows XP, and the customer wanted to convert their workflow to the new operating system.
They made the appropriate changes, and... the problem was not fixed.
At this point, the customer liaison decided to tell us what the actual problem was. (I don't know whether the information was originally withheld by the customer or the customer liaison, so I intentionally phrased the situation vaguely.)
The customer's original workflow involved installing Bulgarian language support, and from your explanation it appears that Bulgarian language support is installed by default on Windows XP. But we still have the problem where if they run one of their internal programs, the text comes out incorrectly unless they also set the Language for non-Unicode programs to Bulgarian.
It took two days before the penny dropped and I figured out what the customer's actual problem was and what they were trying to do.
Even though the customer's original question was asking what happened to "selecting multiple languages from the Language settings for the system" section of the control panel, their actual question is "What happened to the Set default... button that appears below the list box?"
The Set default... button moved to the Languages for non-Unicode programs section of the control panel.
Selecting Bulgarian from the dropdown is equivalent to clicking the old Set default... button and picking Bulgarian.
Back in 2000, some wiseguy named Michael Kaplan walked through the old Windows 2000 control panel and explained what each piece means.
The customer liaison reported back that they could get their program to behave the way they wanted, but for only one language at a time. Reportedly, under Windows 2000, once they added support for Bulgarian and Slovak, they could use the program in both Bulgarian and Slovak mode. But in Windows XP, they have to pick one or the other. If they pick Bulgarian, then the Slovak mode comes out garbage, and vice versa.
The customer's application is Web-based, so the problem may be in the way the program performed language negotiation with the server. But the customer hasn't done any actual debugging; they're just running around fiddling knobs hoping that one of them will magically solve the problem.
What the customer really needs to do is start debugging: For example, they can capture a network trace of the communication between the client and the server on a Windows 2000 machine, and compare it to the trace they get on a Windows XP machine. If there are differences, that may guide the next level of investigation. (And if there aren't any differences, then the problem is strictly on the client.)