Unicode seems that its becoming more and more ubiquitous these days if it's not already, but I have to wonder if there are any domains were Unicode isn't the best implementation choice. Are there any languages or scripts that Unicode will not work well or won't work at all? Are there any technical reasons to use a different system entirely (other than working with legacy systems)? Naturally, I would assume that the answer is to always use Unicode. Am I wrong?
The only time I would avoid Unicode is in an embedded system where the requirements specifically state the system only needs to support a single code page (or ASCII).
Software is almost too easy to reuse. Whether a public project that will be used in ways the author is aware or did not envision, or corporate projects that some suit repurposes, you never know when and where software will be reused. With our global Internet people of all languages may have a use for your software, and it should support languages such as Chinese which are in widespread use and require Unicode to function well.
Embedded systems (a category in which I do NOT include smartphones) are the only domain I can think of that would resist the trend of software being used in diverse locations.
Edit: I just realized I did not really specify why I would avoid Unicode in those situations, even though the answer is fairly obvious. While some combinations of characters and encodings can take up the same space as an 8-bit character (e.g. UTF-8 English), not all will. This can increase space, especially when using characters that necessarily must use multiple bytes (e.g. Chinese, spoken by billions of people). Furthermore, decoding Unicode and transforming it to a glyph on a user interface requires additional code for which an embedded system may not have memory. If I had to develop a routine to transform ASCII characters into glyphs it would likely be a fairly small lookup table, and not involve decoding a variable-length character into a code plane with thousands of glyphs.
ASCII generally uses less memory than Unicode, and doesn't require special encodings. I would imagine that, if you're building a small embedded system for an English user, where the amount of memory is constrained, then Unicode might actually be an impediment.
Unicode is intended for larger systems where you might want to make it possible later to modify the software for other human languages and character sets.
Network protocols. They're almost always defined in 7-bit ASCII. I suppose that falls under "legacy systems."
If it makes you feel better, imagine that SMTP's HELO, EHLO, DATA commands are binary. They're all 4 characters long for a reason.
HTTP GET and the URL and all of the HTTP Headers are also in ASCII.
DNS is most definitely ASCII.
Almost all of the network protocols are implemented first in C and intended for very fast processing. The technical reasons to avoid Unicode here are that the communicating processes are really just exchanging raw binary data. The "words" in the protocol are just to make it readable for people with a network sniffer and so that people can do very basic testing using telnet or netcat.
In these situations Unicode conversion is almost always a waste of time.
Pretty much the only place I can think Unicode would be useful for something like web servers and proxies is case insensitive rewrite rules. Case sensitive rules wouldn't matter because UTF-8 matches just fine without decoding.
Personally, I don't believe in case insensitive processing in network servers or file systems. If the request fails to find a resource, bounce it to an error handler script and it can mess around trying to guess at what the user was really after. That keeps things fast and very simple in the common case.
I would ask "Would you define a new network protocol to use Unicode?" except I am afraid I know the answer. I see people writing nasty, nasty JSON and XML "protocols" all the time. And whoever decided to transfer binary data inside XML in Base64 encoding should probably be shot, drawn, quartered, drowned and then buried alive. "Oooh, gigabit networks! I'll just expand everything hugely and make it impossible to use zero-copy!" Bonus points for then compressing the XML for transfer. Bloat it out, pack it down so you can unpack it and unbloat it. While making three copies some of which are expanding the XML and Base64 data into 32-bit UCS-4 "wide characters". Probably in Java so you can use an extra gig of RAM just because.