I have a legacy application in which the UI and business logic are already reasonably well-separated. There is a proposal to separate them even further, turning the core application into a "service" (without UI) and writing a kind of "UI Server" as part of it to which various UIs (potentially in various languages, and for various different devices and operators) can connect to get/set the data to drive the application via those UIs.
On the surface, this seems to make a nice separation between the business logic, which is currently completely ignorant of the possibility of Unicode, and the UI, which is going to need to get very familiar with Unicode to support multiple languages in the UI(s).
Now this application essentially monitors a production process, and has very little (if any) traffic directly from UI to database via the business layer. It strikes me that the "natural language" of this process might as well be Chemistry or Mathematics, and so internally I should stick to the language that best describes it, so long as I can translate from that language into anything any UI requires (which I believe should be possible). This leads me to prefer (the simplicity and familiarity and least work path of) retaining old-fashioned 8-bit chars over moving to Unicode.
Are there any technical reasons to reject keeping the business logic part of an application ignorant of Unicode like this? And even if the "natural language" of the system were "English-without-too-many-strings-or-dates" rather than Chemistry, would that make a difference?