Separate "timespec" srfi does seem overkill.
I think our best bet is what you suggest below.
One issue I can think of that when a Scheme implementation wants to use reference implementation
of the future date srfi as is, and its timespec implementation differ from the one in its the native posix
interface. It would be confusing for users to have two different data struct with the same
name and operations.
Worse than that, they would not interoperate even if the names were the same. In R7RS, if two record types are defined in different libraries, they are completely disjoint. The only ways to avoid this is for one library to import from the other or for both to import from a third library. (I think this is true in R6RS also, but I am not sure.)
However, I'd imagine it's not difficult for such Scheme implementations to modify
the reference implementation to use its native timespec data structure in date SRFI.
True. I think the Right Thing is to put a timespec definition in a separate file (not library), to be included only on those systems that do not implement SRFI 170, and all others must import from their local SRFI 170. This is easy to do with cond-expand.
Another issue is that if Scheme implementation doesn't allow to import the same identifiers
from different libraries (as in R6RS); in that case, a user code that uses srfi-170 and date srfi needs
some extra renaming or excluding in import clause. Is it the issue you want to avoid?
That's also a problem. I have always tried to make sure that no two libraries in R7RS-large export the same identifier unless one is a complete replacement for the other, such that there is never any point in importing both libraries; or one library is importing from the other and re-exporting, which is safe.
Doing otherwise means a careful check and (import (only ...)), unless the implementation is polite enough to complain about such import conflicts in detail rather than just saying "Import conflict between (foo) and (bar)" or worse yet letting the second import override the first.