Draft 6 says that it's an error for an argument of / (other than the first) to be an exact zero. R6RS, however, says that it's an error only if all the arguments are exact. In other words, (/ 2.0 0) is an error according to the draft, but in R6RS it returns +inf.0 (assuming the implementation supports it). The proposal is to adopt the R6RS wording.
I tested (/ 2.0 0) in the usual set of Schemes:
WG1 decided to make no change, keeping the R5RS rules.
Here is a Galilean dialogue between Sixer, a proponent of the R6RS rule, and Fiver, a proponent of the R5RS rule, which is the same as that of R7RS draft 6.
Sixer: Why shouldn't / should do inexact contagion, just like the other arithmetic operations?
Fiver: Because an inexact operation may return an exact result if it can prove that the inexactness can't affect the result, like (* 1.0 0) returning 0 rather than 0.0.
Sixer: Certainly. But what has that to do with it?
Fiver: Dividing by exact 0 doesn't care about the inexactness of the other arguments. There is no exact infinity in Scheme, so it's more appropriate to report an error representing the non-existent value. Since we don't require errors to be signalled except in a few circumstances, "is an error" is the appropriate phrase.
Sixer: The value +inf.0 can be understood as covering both overflow and positive affine infinity. Surely that's the least surprising result when inexact numbers are involved?
Fiver: But why should the result of dividing by an exact 0 be positive rather than negative? Zero, after all, is neither.
Sixer: I don't know, man, I didn't do it, but IEEE 754 says so.
Fiver: Well, anyway, "is an error" covers both raising an exception and returning +inf.0.
Sixer: True, but numerical programmers expect to be able to rely on the IEEE rules, instead of the bad old days when division by zero always crashed your program.
Fiver: Then let them avoid exact numbers.
Sixer: Maybe. Is that realistic? I don't know.
Fiver: Me either.