Testing Right-To-Left text is interesting though, as I am not even sure there is an unambiguously sane way that terminals can interpret changing directions. What is supposed to happen, if I explicitly set the cursor position adjacent to existing mixed-direction text? Should the existing text in this cursor position influence how new text is formatted? Or should that only happen if I output a sequence of characters without intervening escape codes? How about when I change the terminal from overwrite into insert mode? Does that change behavior? How does cursor positioning work when it encounters mixed text? Is the answer different for relative and absolute cursor positioning commands?

While it is certainly possible to come up with *an* answer to these question, I doubt it is the only answer. I'd expect that each implementation does something different, resulting in behavior that is so hard to predict that no application could rely on anything but the most basic set of features. But who knows, maybe there is a standard for this and I just don't know about it.

All of this gets even more complex for languages like Arabic that require ligatures (or shaping) to make the text intelligble. You can no longer think of a word as being made up of distinct characters, but you have to look at most or all of the word to figure out how to render it. I have a really hard time seeing how terminal emulators can provide a sane implementation with these constraints. It pretty much breaks all assumptions about a fixed grid of characters, and about the ability to arbitrarily position the cursor to any X/Y coordinate. Y coordinates still make sense (until we consider vertically-rendered text), but X coordinates are getting increasingly fuzzy.

I'd love to hear if there is a universally agreed upon convention how to handle this problem, and whether there are any terminal emulators that correctly implement all the corner cases.