First off, I think Word Processing really falls under the greater category of "Professional 2D Document Publishing", something that also includes graphics and DTP. (Perhaps this page is misnamed, but I figured a 12 sylable name would be a bit obnoxious.) The future of such publishing seems to be heading towards, and should head towards, much more modular, flexible and open architectures, architectures, perhaps such as OpenDoc and OLE, where small, managable-sized components are stacked together to build much more friendly, usable working environments.
In Tunes, there should exist seperate text, graphics, spell-check, thesaurus, ... modules, each of which is loosely integrated with the rest, and each of which is easy to replace, should a better or preferable version come along.
My personal preference is towards WYSIWYG interfaces, somewhat like (though much more OO than) today's DTP packages, or perhaps even ClarisWorks. However, how such interfaces could be readily created in text-only mode, some auditory-only mode, or through some other "strange" method of interaction, remains a mystery to me.
What I'd like to do is a better, cleaner, TeX. It would be reflective, but in a semantically clean way, rather than with uncontrollable macros that have to be written in low-level continuation-passing style for anything complex. You'd have all the power of the Tunes HLL, with a collection of predefined concepts and tactics corresponding to 2D typesetting.
Because this would be cleaner, a set of structure-based editing tactics for this language could be done, and guess what? it would be the very "word-processor"! By not creating meta-objects, or only very simple ones, and not using the language's capabilities, casual users end up with the very same as current word-processors.
but because every single sub-object of their document is a first-class Tunes object, and any first-class Tunes object can be embedded in their document, they can trivially achieve what is so difficult to classical systems; for a Tunes-embedded object is not just for display; any Tunes operation can be done on it.
Hence, I could study some problems, acquire data in a specific format with specific semantic operators; treat this data in many ways; define functions and concepts to manipulate a large class of data, define styles to display the data in various ways, and automatically generate from my same Tunes workplace lots of information extracts as 2D documents:
Because Tunes can manipulate side-effective structured objects instead of isolated linear bytestreams, it removes the problem of having to explicitly copy object representations and references, with all the associated desynchronization problems (about this latter problem of current systems, see Tunes against the WWW), etc.