O.k., here are now some general remarks.  Tony asked

  Also, why are you interested in writing an R-mode, rather than
  modifying the S-mode?  I'm curious as to what features you feel are
  needed?  or is it simply a matter of avoiding code bloat?

Let me try to answer that.

* Apparently, S-mode currently is not maintained.  This is a real
problem.  I don't know if Richard Stallman (hereafter, RMS) is currently
aware of how well R is progressing.  I am sure he would eventually love
to include it into the `GNU' distribution, and I am also sure that he
will like to include support for it in GNU Emacs.  This means that code
will have to be cleaned (and copyrights transferred etc).  No
maintainer, and code which is not `clean' ... no inclusion.

* Another crucial problem is terminology.  If the documentation keeps
talking about sending to an S process etc, and it is in fact an R
process ...  I am not sure how users feel about that.  I am also not
sure how much Ross & Robert want R to be treated as markedly different
from S, or what the authors of S-mode think of that.

* I've encountered a similar situation with MATLAB and Octave.  An Emacs
MATLAB mode had been around for quite a while.  Eventually, John Eaton
(the author of Octave) modified this to work under Octave, too (which is
harder because there are syntactic differences as well).  This did not
work satisfactorily.  Two more hacked-up MATLAB mode versions appeared
(one by me).  So, John wrote a new Octave mode based on F77 mode.  Of
course, this was not the optimal thing either.  Eventually I ended up
writing octave-mode (plus I/O stuff etc) from scratch.  This code will
now be included in the next version (19.35) of GNU Emacs, and from what
I heard also runs without problems under XEmacs (which I cannot confirm
because I use GNU Emacs).

In a way, the situation Octave/MATLAB is very similar to R/S.  It might
have been possible to have a joint mode, but it turned out to be more
convenient otherwise.

* Another thing is, what happens if we start putting even more effort
into improving R support in S-mode.  Will this eventually be merged into
the `proper' S-mode distribution?  

* Thus, the question is whether it is both possible and feasible to have
a package which FULLY works under R and S AND solves the obvious
documentation problems.

(And of course, we know that there are major differences in the I/O
system, for example.)

Please let me know what you both think about this.

-k

PS.  From the length of this message it should already be clear that I
am willing to put some time into this :-)