Allowing examples like these will make code-walkers (including compilers and interpreters) excessively complicated:
I'm not proposing that an error be signaled. It's simply that code like the above is incorrect: you can't rely on it doing something in particular, never mind "the obvious thing". That is what "is an error" means in the Scheme standard.
Do we really want this to be considered an error at all? I could imagine writing a program that used such a chain, though I cannot think, at the moment why I would do that. My point is basically, does it really hurt anything to let implementation apply a reasonable semantics to it if they can find one? I like unspecified better.
If it's a meaningful extension in some Schemes, then (as I said) code-walkers have to accommodate it.
It is possible to construct this situation in current implementations of R5RS and R6RS, so how do code walkers handle this situation currently? It is trivial to handle this situation in a code walker by not-terminating; is this incorrect behavior? What is the current practice when dealing with these forms today? Do any of them consider this to be an explicit or implicit error situation? Neither R5RS nor R6RS handle this explicitly to my knowledge, is it worth it for us to do so? Why complicate the language with this? I don't think it is worth it and I don't think it buys us anything.
We voted to note this is an error.
My initial thoughts are, why? We already have non-terminating expansion, and at least one major Scheme implementation handles this by looping forever. I would think that detecting the loop is more expensive than just letting an implementation loop.
Doing this would complicate the expander, and I wonder if this is worth it. What do existing Schemes say about it?