This is a generic answer as of compatibility of TUNES with existing systems and standards in general.
We are committed to embracing established standards when they exist. When we deem these standards unfit, which will no doubt often be the case, we will strive to provide a replacement, as well as an upgrade path, through dynamic emulation and/or static code conversion.
However, compatibility with a given system being but some particular kind of functionality, see the above question about when some functionality will be available in TUNES.
Now, TUNES is so much different from existing low-level systems, that the generic answer should be: no, TUNES won't be compatible with given system. However, TUNES will nonetheless strive to run programs designed for existing systems through a combination of binary emulation and source conversion packages. Both binary emulation and source conversion are widely known and used techniques, and there are lots of programs running on e.g. GNU/Linux to emulate other architectures or operating systems, or convert programs written for different languages/environments.
Alan Perlis once said: "A programming language is low level when its programs require attention to the irrelevant." We think the Unix API in particular, and actually the whole of current computing systems, are much too low-level, and unfit for general programming of high-level communicating agents.
However, we do acknowledge that an enormous mass of useful free (and unfree) software has been written (and is still being written) on top of this API, so that, until all this software is reengineered to work with better APIs, and even afterwards for the sake of retro-computing, we will provide compatibility with as much of this API as possible.
This compatibility will be achieved in two complementary ways, as described in the generic answer. The first, shorter term, way, is to support binary emulation of Linux programs inside paranoid isolation boxes (whereas native TUNES code runs without such boxes), by developing our PIG subsystem (PIG IS GNU). The second way is to develop a source analyzer for C code that will allow to decompile C code into higher level code that can integrate with the TUNES system in smoother ways as well as detect and remove such bugs as buffer overruns et al.
Now, "native" TUNES code won't use anything remotely resembling the Unix API. For instance, a large part of Unix deals with meddling with files and otherwise manipulating raw sequences of bytes, as a way to explicitly handle persistence and exchange of data in explicitly defined low-level formats; in contrast, native TUNES code will have orthogonal persistence or high-level data-structures, and hence, no need for such a low-level concept as a "file", no ubiquity of sequences of bytes.
Finally, we do intend to use free Unices (Linux, *BSD) as both cross-development and underlying run-time environments until TUNES is mature enough to fully replace them, so that we will rather have a TUNES-over-Unix compatibility layer than a Unix-over-TUNES compatibility adapter.
We do hate Windows and similar misdesigned bad quality low-level proprietary software; we particularly hate the constraint of binary and hardware compatibility induced by their business model, that is maybe the main brake to progress in the computer industry. But even then, we have hopes that, in the long run, TUNES would support compatibility with even the lowliest existing systems, including Windows, if there is any use for it (which might not be the case anymore by the time we're ready to handle it).
It seems that shortest path to such support would be "simply" to run WINE inside our PIG subsystem (GNU/Linux wrapper); further integration of it into TUNES would be achieved by patching (or otherwise metaprogramming) WINE and/or the subsystem.
We have no desire to write such a compatibility layer ourselves from scratch, and considering the huge size of the bloated legacy Win32 API, we see no interest in wasting resources in efforts redundant with WINE. If what you want is free software Windows compatibility, do have a look at WINE. In case there be something in the WINE project you dislike, you may improve it by contributing to WINE, which is a free software project. And in case the WINE people ignore your contributions (why would they?) you may split their project, since their software is free! In any case, people who claim to reimplement Win32 compatibility without even citing the project WINE and giving reasons not to just collaborate with it are just being ridiculous.
We know of no system that has the general feel of what we want TUNES to be. However, we can have get a rough idea from former or surviving integrated development systems where the source code is dynamically available. Such systems include those used on the Lisp Machines of old (some of them also Smalltalk machines), or Squeak (free software implementations of Smalltalk), or maybe some Self or Forth or Oberon systems or Pliant. In these systems, program code is "live"; incremental modifications take immediate effect. Software is not "dead" in files that must be statically compiled and executed from scratch everytime.
Now, the goal for TUNES differ notably from the above systems: firstly, all these systems were mostly centered around having a one global language, a one image, a one environment, etc. This means that as far as metaprogramming goes, these systems are mostly autistic; they have no support for multiple nested computational systems, computing or reasoning on well-defined closed subsystems. Now, such well-defined closed subsystems are necessary for managing multiple users, for security concerns, for mixing real-time and usual computations, for proving meaningful whole-system program properties, etc. Also, none of these systems (except experimental ones that were never used, or the good old deceased Eumel) are or were orthogonally persistent - you can have variables persist, but you must dump images explicitly, which is a very costly operation (however the Lisp Machine did have a nicely integrated transactional object database).
See the above question and answer for a general response. More specifically, key features in which TUNES will differ from Lisp Machine systems of old are:
Also, there are lots of nifty features and applications that Lisp Machine systems had that we will not dare try to implement for quite some time, from the windowing interface to MACSYMA, from the 3D software to the documentation tools. We do hope that we will eventually have some of these, and that someone somewhere will implement such things on top of TUNES; we might even develop skeletons of such software, for our own purpose, or interface to third party such software; but they do not constitute the heart of the project.