Shiro Kawai <xxxxxx@gmail.com> writes:

| 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?

You're absolutely right.  I was worried about making this
change, but it seemed to be a genuine mistake, and therefore
that it was legitimate to make a correction after
finalization.  Nevertheless, I should have called out the
incompatible API change.

As you suggested, I've updated the Status section to
describe each errata change briefly, and I've added a note
next to `vector-cumulate' explaining what was changed and
when.

I've updated my checklist so that future non-trivial errata,
especially any with incompatible API changes, will be
treated the same way.

Thanks for pointing this out, and for your suggestions.