When we round, say, a floating point number 1.15 in 100th place (round to nearest 10th), there can be two interpretations.

* Look at the floating point number represented by 1.15 and see if it's closer to 1.1 or 1.2. If we use binary flonums, the flonum represented by 1.15 is smaller than 115/100, so we print 1.1.

  Let's call this effective rounding.

* Take the notation 1.15 itself and apply elementary math.  We print 1.2.

  Let's call this notational rounding.

Some popular programming implementations adopt the former.  For example,  printf("%5.1f", 1.15) in C prints "  1.1" (using gcc).

If we apply binary-to-decimal converter with proper boundary checking (Burger & Dybvig 1996), we get the effective rounding.

If we generate the optimal decimal approximation, then tweak the result string to do the rounding, we get the notational rounding.

Each has its own merit; effective rounding is consistent with internal treatment of flonums (we treat it as a value (* sign mantissa (expt 2 exponent)), with allowing errors in some operations). but it sometimes causes confusions among users, who's perplexed by getting 1.1 out of 1.15.

Recently I implemented ~w,df formatter in Gauche, and I support both rounding modes, switched by flags.

Since Scheme doesn't specify internal representation of flonums, the result of effective rounding could differ.  Notational rounding would give consistent results across wider implementations.

Rounding is inherently an approximation, so we don't need to specify too much.  But I have a couple of suggestions:

1. Mention the possibility of this difference among implementations.  For example, Common Lisp's format has this:

"When rounding up and rounding down would produce printed values equidistant from the scaled value of arg, then the implementation is free to use either one. For example, printing the argument 6.375 using the format ~4,2F may correctly produce either 6.37 or 6.38."

2. (Optional) Add a mode to guarantee notational rounding.  I've seen enough cases that the user reports the "bug" that it doesn't round as expected.  Would be nice if we have a portable way to guarantee consistent results.