This change is good and I support it, and I regret I didn't catch it in the draft period.
I'm worried, though, that such instances that the specification itself is amended
after finalization would keep happening.
Gauche added srfi-133 support soon after its finalization. Fortunately I haven't
made a new release since then, so I can fix it. If I've already made a release,
it would've been a bit different story. It happened in srfi-13; the argument order of
string-filter and string-delete was changed after finalization. I ended up to
make Gauche's version accept both order so that it wouldn't break existing code.
In vector-cumulate, it could be indistinguishable whether the caller intends
old or new interface (in case knil is a vector), so such ad-hoc fix wouldn't be possible.
Mistakes and overlooks happen, so it's unrealistic to completely prohibit
post-finalization amendment. What I like to see is that compatibility breakages
such as argument order change to be more prominently advertised than smaller
fixes. For example, the Status section can note there was an incompatible API
change, and also vector-cumulate entry can note the argument order is reversed
by the post-finalization errata. How about that?