I would tone down some of the language

[Ray Blaak <blaak@xxxxxxxxxxxx>]

I applaud this effort to simplify things. However, a reference document 
should try and avoid the hints of past fights, tense emotions, 
flamebait, etc.

In particular, this:
> Two days later, Dybvig proposed a "compromise" along those lines [11] 
> that incorporated several artificial restrictions, apparently because 
> Dybvig feared his compiler would be unable to generate efficient code 
> for the general case. [12]
is better as:
> Two days later, Dybvig proposed a "compromise" along those lines [11] 
> that incorporated several artificial restrictions, due to efficiency 
> concerns for the general case. [12]
And this:
> Meanwhile, gratuitous design errors impede interoperation between 
> procedural and syntactic layers, and several bogus claims about the 
> inefficiency of higher order procedures were inserted into the very 
> last public draft and were then ratified as part of the R6RS. [17]
is better as:
> Meanwhile, design errors impede interoperation between procedural and 
> syntactic layers, and several invalid claims about the inefficiency of 
> higher order procedures were inserted into the very last public draft 
> and were then ratified as part of the R6RS. [17]
If necessary, put in a paragraph that addresses the efficiency issue 
with higher order procedures directly, e.g. "we show that the efficiency 
concerns related to higher order procedures are in fact not valid..."

Remove words like "bogus", "gratuitous", hints of sarcasm, etc.

Note that I am not saying you are incorrect with those words :-). It is 
just that the communication of the ideas is more effective if the 
reasons for things are made directly clear. When the disputes are long 
forgotten, this document will still serve as an implementation 
reference, and that is the purpose it should be optimized for.

Cheers,
Ray Blaak