While specifying quasiquote semantics, a few things came to my
attention.

- You might often want a fresh version of a certain hashtable, which
  contains no entries but has the same hash function, equivalence
  function, and weakness as the original.  This is way too difficult
  normally (have to manually check if it's an eq? or eqv? table), and
  now there's a procedure that does just that:

    (hashtable-clear-copy ht)     ;initial capacity has default value
    (hashtable-clear-copy ht #t)  ;initial capacity set to ht's current size
    (hashtable-clear-copy ht 512) ;initial capacity set manually

("Clear" is an adjective here, not a verb like in hashtable-clear!.)

- That fulfills the most common use case, but nevertheless it's annoying
  that the values returned from the inspection procedures can't directly
  be passed to make-hashtable to create the same kind of hashtable.
  There's no reason it shouldn't be able to special-handle eq? and eqv?;
  it would impose a trivial change to the implementation at most.  (And
  in some implementations the dedicated eq? and eqv? constructors might
  already be delegating the job to make-hashtable.)  So now you can:

    (make-hashtable (hashtable-hash-function ht)
                    (hashtable-equivalence-function ht)
                    #f   ;or (hashtable-size ht)
                    (hashtable-weakness ht))

  which is pretty useless when you have hashtable-clear-copy, but it
  fixes an inconsistency in the API, simplifies the implementation of
  hashtable-clear-copy, and one can imagine the hash and equivalence
  functions being copied but the weakness changed, etc.

- The hashtable-map in SRFI-125 happens to fit perfectly into the
  use-case of implementing the quasiquote semantics I specified, which
  made me wonder whether it's a fine candidate for standardization after
  all, despite its strange semantics.  I decided against that, precisely
  because I dislike the quasiquote semantics I ended up specifying as
  well (will keep them simply because I couldn't see a better way).  So
  I stand by my belief that SRFI-125's hashtable-map has strange
  semantics that are undesirable in the general case, although I haven't
  added Takashi Kato's proposed hashtable-map either yet (still
  pondering on it).

Taylan