> My concern is that although numbers are not a scarce resource, having a
> zillion Draft: lines in the Status section pushes the actual content
> further down the page.

Agreed.

> Batching works fine for DIY authors, but when
> the interface is being worked out collaboratively, it's probably
> important to publish every time *something* is agreed upon.  On the
> gripping hand, we don't want to drown reviewers in drafts either.

I would say it depends on how substantial the change being agreed upon
is. E.g. in SRFI 170 we could decide to change an argument that affects
how a procedure handles symlinks. That's clearly an API change but it's
a very minor one given the scope of 170. If we changed how _all_
procedures handle symlinks, that would call for a new draft.

If the collaboration happens on the SRFI's mailing list, and we use
halfway sensible subject lines in our email threads, people can monitor
the threads in their email reader to spot things of interest to them
even if there's no new draft.

> Furthermore, semver is about warning people about incompatible changes,
> but drafts are "use at your own risk" anyway:  Draft #5 should be
> understood in semver terms as 0.5 or 0.0.5, depending.

Incompatible spec changes in a draft often signify a change in design
direction. I think that's analogous to a semver API change. It doesn't
make a difference that the SRFI is not finalized.