本報告書では、手続きの引き数と構文形式の下位形式が厳密に仕様に適合しているかどうか確認することを求めている。ただし処理系は仕様で定められた違反を各個に検出する必要はない。仕様としては、次の例外を認めている。
二番目には特に注意が必要である。本報告書に対して成した特定の決定により、可能なかぎり多く違反や可搬性のない仮定を検出するような「神経質」な処理系をつくることもできるし、プログラムを高速に実行することのできる現実的な実装を実現することもまた可能なのである。
R5RS では多くの状況を「エラーである」として規定されないものとしていた。すなわち、可搬性のある R5RS プログラムでそのような状況を起こすことはできないが、一方で、R5RS の実装系はこのもとで任意の振舞いを実装してもかまわなかった。任意の振舞いというのは、実行中のプログラムを「クラッシュ」させることも含んでい、完全性について妥協し、結果として実行モデルがランダムになっているとも言えた。これは、Scheme が「安全」な言語であることと一線を画していた。そのためには、言語規約や処理系の定める制約への違反は各々少なくとも定義された振舞いをしなければならなかった（例えば、プログラムを中断や停止させたりデバッガを起動するなど）。
このような任意の振舞いに関連した問題を避けるために、本報告書に規定されたライブラリはすべて安全であり、仕様への違反を検知した場合には例外を送出しなければならない。このとき、プログラムは違反自体を検知し、それ自体に対処してもかまわない。
本報告書では安全性を侵害するような「危険」なライブラリを実装側が提供することも認めている。
末尾呼び出しで使われる継続の意味はその呼び出しを含む手続きの継続に含まれるため、当該の末尾呼び出しのために空間が必要でないことは直感的にわかる。不適切な処理系では、末尾呼び出しにおいて新たな継続を渡すことがあるかもしれないが、この継続へ戻ると即座にもとの手続きの継続へと戻るであろう。真正末尾再帰的な処理系ではもとの継続に直接戻るのである。
真正末尾再帰は Steele と Sussman の Scheme の原版の中心的な考えでもあった。彼らの最初の Scheme 解釈系では関数とアクターの両方を実装した。制御の流れはアクターで表現し、アクターは関数とは異なり、結果を返す代わりに別のアクターに渡すようになっていた。本報告書の用語で言えば、各アクターは最後に別のアクターへの末尾呼び出しをしていた。
後になって Steele と Sussman はその解釈系のコードでアクターを処理する部分が関数とまったく同じであることに気がついた。これら両方を言語に含める必要はないのであった。
真正末尾再帰が初期から Scheme の基盤であるのに一方で、いくつかのアーキテクチャ、特に、C 等の、より高レベルの中間言語に翻訳するものや、JVM や CIL といった特定の仮想マシンにおいては、効率的な実装が難しくなっている。
にもかかわらず、言語仕様としての真正末尾再帰を捨て、可能な最適化に格下げしてしまうことには広範囲にわたって影響をもたらすであろう。例えば、多くのプログラムは真正末尾再帰がもう使いものにならないと仮定して書かれたであろう。さらに、真正末尾再帰なしではアクター型のメッセージ受け渡しシステムや自己書き換え型サーバー、相互再帰的な手続きで書かれたオートマトン等のような特定のプログラミングスタイルを自然に表現できないであろう。さらに、真正末尾再帰をなくしてしまった場合には、一般的な繰り返し構文の穴を埋めるために、特別の「ループ」構文を追加する必要があるであろう。