My feeling is still ambivalent, but since there's not much discussion, I'll jump in.
I think John's suggestion is a clever workaround; there's no reason that salt should be a
positive integer, so let's set it in a range that doesn't conflict existing srfis---makes sense.
On the other hand, it does look like a huge wart that I wish I wouldn't have to see.
How many Scheme implementations are there actually using bound argument? I mean,
Gauche does support srfi-69, but Gauche's native hashtables don't use bound arg; it always
calls the hash function with one argument. Our srfi-69 module exports srfi-69 compatible
hash function that does accept optional bound arg, which is just a wrapper of native
hash function.
If salt is adopted, I'll make use of it in internal hash table, and I'll put wrapper
around hash functions passed to srfi-69 hashtable creation api, that is,
srfi-69's (make-hash-table equal-fn srfi-69-hash-fn) would wrap srfi-69-hash-fn by
(lambda (obj salt) (srfi-69-hash-fn obj)) --ignores salt and doesn't pass bound.
It affects performance, but I don't care much; it's just to run libs that uses srfi-69,
but I count on that future libraries uses the newer srfis (that we're discussing)
and I'd rather tune for it instead of caring to-be-obsoleted srfi. In short, I'd rather
expect a clean API for the new srfis. (This is only my personal view; I understand
that some would value backward compatibility more, especially if they have large
existing libs that relies on srfi-69 hash api. I honestly don't know how much such
code are there.)