ある時点で仕様が一致しなかったとしても、必ずしも構文エラーが報告されるとは限りません。代わりに、すべての選択肢が尽きるまでバックトラッキングが行われます。最終的には、引数リストのすべての要素が仕様内の何らかの要素と一致し、かつ仕様内のすべての必須要素が何らかの引数と一致しなければなりません。
構文エラーが検出された際、より上位の代替案が尽き、指摘箇所が実際のエラーから遠ざかったかなり後になって初めて報告されることがあります。しかし、エラー発生時にバックトラッキングが無効になっていれば、即座に報告することが可能です。なお、バックトラッキングはいくつかの状況で自動的に再有効化されます。具体的には、&optional、&rest、または&orによって新しい代替案が設定された場合や、サブリスト、グループ、または間接指定の処理開始時などが該当します。バックトラッキングの有効化または無効化による影響は、現在処理中のレベルの残りの部分およびそれより下位のレベルに限定されます。
いずれかのフォーム仕様（すなわち form、body、def-form、および def-body）にマッチしている間は、バックトラッキングが無効になります。これらの仕様は任意のフォームにマッチするため、いかなるエラーも上位レベルではなく、フォーム自体に存在する必要があります。
引用符で囲まれたシンボル、文字列指定、または &define
キーワードのマッチングに成功した後も、バックトラッキングは無効になります。これは通常、認識済みの構文であることを示すためです。ただし、すべて同じシンボルで始まる代替構文のセットがある場合、通常はそのシンボルを代替構文から切り出すことで（例：["foo" &or [first case] [second case]
...]）、この制約を回避できます。
ほとんどのニーズは、バックトラッキングが自動的に無効化されるこれら2つの方法で満たされますが、場合によっては gate
指定を用いて明示的にバックトラッキングを無効化することが有用なこともあります。これは、より上位の代替案が適用されないことが分かっている場合に有効です。let 指定の例を参照してください。