Perhaps a vote for adding it??
I have an issue with it, namely that it suspends the current Posix thread, but Scheme threads don't necessarily match Posix threads 1:1, in which case it would have to be multiplexed using the Scheme implementation's event loop. I'm not sure that's worthwhile given that you only get millisecond precision. Sleep can never affect correctness in properly written threaded programs.
Alternatively we'd have to document that sleep may suspend threads other than the current one.
This very limited timespec SRFI sounds ... very limited.
The main reason for the timespec SRFI to get rid of the shared-structure issue, since it will be shared between at least two SRFIs, probably more. For that to work, constructor and accessors are necessary and sufficient. Adding comparators just makes sense in the general R7RS-large scheme of things.
It occurred to me that a timespec-as-interval is just an absolute timespec with an unusual epoch. So I'll add a procedure `timespec-new-epoch` which takes two timespecs which share an epoch and returns the first timespec with its epoch changed to the second timespec. This is just timespec subtraction under a different name.
That's for async IO. I don't think we should expose async IO at the user level (though as I have been saying it's pretty much necessary in the implemnentation event loop).