There seems to be a serious issue with how we handle keywords (by which we mean, things like the else in cond). R5RS was vague on the matter, and each choice of implementation approach seems to have issues.
The R6RS standard decided to use explicitly exported and defined auxiliary syntax values, where every syntax-rules literals clause matched hygienically using free-identifier=?.
Let's summarise the issues with different approaches.
One approach is to say that the implementation of cond must match a symbol called else - so it's purely symbolic equality, rather than bothering about lexical environments.
Problems: See this thread: http://lists.scheme-reports.org/pipermail/scheme-reports/2011-May/000632.html
Particularly, symbolic equality bypasses the normal identifier equality tests used by syntax-rules, thereby violating referential transparency and hygiene in some cases.
Under this scheme, else is bound to something (a value? a macro? a pineapple?) along with the definition of cond, and we check that the same binding is in place when else is used in the wild.
This means that if we do:(let ((else #f)) (cond (else 1))
...we'll get an error, not 1, as we've rebound else; that arm of the cond will evaluate else and get #f, so no arm of the cond matches.
However, it has another issue. Andy Wingo, I believe, gave an example of a module that exposes both compile (a procedure) and eval-when (a macro that uses compile as a keyword). It's then impossible to expose eval-when into a sandbox, still able to use the compile keyword, without then also giving them the compile procedure.
Please add alternative implementation techniques here, and discuss their problems and characteristics.