That's right, and there I still haven't got a clear opinion. Using round-half-to-even would be consistent with round, and probably so in other parts of the implementation (e.g. the built-in string->number and number->string might be using round-half-to-even whenever tie-breaking is required).
Initially I implemented Gauche's notational rounding with round-half-to-even. But then I thought it might not be what users expect---when a user thinks 5.015 rounded down to 5.01 is a bug, she is assuming round-half-to-infinity. I assume nobody would pick on statistical bias after notationally rounded numbers so I changed Gauche to use round-half-to-infinity. It does appear to be an arbitrary choice.
Maybe this complexity is the reason that many programming language / implementations are vague on this. It's not worth to define precisely, they think.
Here are some options I can think of right now:
Option 1:
We take the same path with others, just saying numbers falling near the midpoint may be rounded up or down, it's implementation dependent.
Option 2:
Potentially over-engineering specification:
* Must have a way to guarantee notational rounding (it's ok to only provide notational rounding; the impl may provide more efficient, native effective rounding as an option)
* Have an option to specify round-half-to-even or round-half-to-infinity
* Say exact number must be treated exact while generating digits, e.g. converting it to flonum first isn't an option.
If we go down this strict path, we might end up providing full Burger&Dybvig algorithm in the reference implementation, to guarantee the consistent digit generation across implementations.
Option 3:
Make the option 2 an "option", and add some mechanism to query what the implementation provides.
It reduces the burden from the implementors. Easier for the implementation that already has customizable flonum formatter to adopt srfi-159.
An application that prefer notational rounding at least can warn users if it's not the case.
Option 4:
Make the number formatter pluggable. Can be done with the current spec by just replacing numeric, but we can also define lower-level callback that only generates digits (comma etc. are handled in srfi-159). The default is implementation-dependent (with the loose definition like option 1). Separate srfi would provide various digit generators. Can be combined with option 3.