Chris Hanson
Chris Haynes
Dan Friedman
David Bartley
Don Oxley
Eugene Kohlbecker
Gary Brooks
Hal Abelson
Jonathan Rees
Kent Pitman
Mitchell Wand
Norman Adams (or Norman I Adams IV, assuming this name references the
same author)
Robert Halstead
William Clinger

Instead, we suddenly see the appearance of the following authors for
R6RS, who had never appeared in any of R2RS - R5RS:

Anton Van Straaten
Jacob Matthews
Matthew Flatt
Michael Sperber
Robert Bruce Findler

In fact, the only person common in the lists between R3RS - R5RS
(according to the chart, he was not an author for R2RS) and R6RS is
Kent Dybvig.

(What follows is a rather long and possibly controversial discussion
of the possible reasons for this division of authors between R2RS -
R5RS, and R6RS; please read only if you don't mind reading a long
discussion; otherwise, just skip the rest of this message, please.  My
aim is to try to analyze and understand what happened between R5RS and
R6RS, and why.)

<monologue>
What happened to all the previous authors, and who are these new
authors?

Well, I know of both Matthew Flatt and Robert Bruce Findler from PLT
Scheme.  They are members of the PLT Research Group, and they
regularly post on the plt-scheme mailing list.  (They have both been
very helpful on many occasions, so I have no qualms against them
personally; I am just trying to analyze their motivations for R6RS.)
They are both also among the authors for HtDP.  They are also among
the co-authors for the influential paper "The Structure and
Interpretation of the Computer Science Curriculum" (see
http://www.ccs.neu.edu/scheme/pubs/jfp2004-fffk.pdf).  According to
that paper (see pp. 6-7, in section "3.1 Functional and
object-oriented programming"), they write as follows:

This is an issue of basic teaching philosophy.  As an example of the
third viewpoint, Shriram Krishnamurthi writes on the plt-scheme
mailing list as follows (see "[plt-scheme] Re: More pedagogic stuff"
at
http://list.cs.brown.edu/pipermail/plt-scheme/2008-August/026424.html):

This is usually not a problem, so long as this taste is confined to a
particular implementation.  The problem with R6RS is that it is not
just an implementation; it is a standard that can affect all
implementations.  R6RS, compared to previous revisions, makes a
dramatic number of changes to the Scheme standard.  Each one,
individually, is not such a big problem; it is the entirety of all
these changes taken together without sufficient discussion that is the
problem.

The members of the board had to vote for all the changes taken
together, rather than each one separately.  A standard usually should
require a consensus; however, this consensus was not really achieved
in the case of R6RS (read through the reasoning behind both the "yes"
and "no" votes in the "R6RS Ratification Vote" at
http://www.r6rs.org/ratification/results.html, and you will see the
scope of the division).

Some of the main points of this division seem to be the following
(apologies to those whose votes are not listed below; I have listed
only the votes of names that sounded familiar to me, but there were
many other significant votes, which were omitted not because of lack
of significance, but because of lack of space and time):

the module system (see votes by Chris Hanson
(http://www.r6rs.org/ratification/results.html#X78) and Taylor
Campbell (http://www.r6rs.org/ratification/results.html#X100))

SYNTAX-CASE (see the vote by Chris Hanson above)
the switch to case sensitivity (see the vote by Jonathan Rees
(http://www.r6rs.org/ratification/results.html#X91))

defining too many features as part of the language, rather than on top
of the language (see the vote by Nils M Holm
(http://www.r6rs.org/ratification/results.html#X94))

lack of time to change the draft to meet the deadline of the
ratification draft (see the vote by Shiro Kawai
(http://www.r6rs.org/ratification/results.html#X99))

too long description of the specification (thrice the previous one);
restrictions on implementation design that impede future development
of the language in the areas of numbers, text manipulation & Unicode,
and the module system; overreach of the module system's definition
(see the vote by Taylor R Campbell
(http://www.r6rs.org/ratification/results.html#X100))

Even some of the "yes" votes list "imperfections" that "troubled"
them:

apparent inflexibility of the library system, and absence of a
facility analagous to Common Lisp's reader macros (see the vote by
Alexey Radul (http://www.r6rs.org/ratification/results.html#X2))

In sum, it seems that R6RS was at least partly motivated by a
perceived need by at least some of the new authors for a standard of
Scheme that would help ease the transition between the functional and
object-oriented paradigms.  Apparently, at least some of the authors
perceived that adding more features to the core language, instead of
defining a small core language and adding features on top of the
language, would help with this transition.

Another problem was lack of time.  R6RS seems rather rushed compared
to previous specifications.  There probably should have been more
discussion before finalizing the specification.  In particular, there
should have been some means of voting on each potential feature
separately, instead of on all of them together.  It is quite possible
for each feature alone to be quite useful, but for the combination of
all of them put together suddenly at once to be quite problematic.
</monologue>