I have several comments concerning this proposal, so I have
split them up into multiple messages that deal with orthogonal
issues.  I'll sometimes refer to Gambit, which has support for
hash tables in the latest unreleased version.

I'll start with naming issues.

You have named the data type "hash table" and this is certainly
consistent with past practices in Scheme and Lisp.  In Gambit
(and Scheme48 and T) the data type is simply called "table" because
a hash table is one of several possible implementations of a table.
Semantically your hash tables are fundamentally a structure associating
keys with values.  This can be implemented with hash tables, search
trees, association lists, and many other ways.  I prefer to
separate the interface to a key/value mapping from the
implementation.  By calling it a "table" and providing table
creation parameters that allow the user to select the
implementation, you get a higher level of abstraction, which
is a good thing (allowing you for example to switch between
implementations by only changing the table creation parameters and
not all the table operation call sites).

The basic table operations are named as follows in Gambit:

   (make-table [optional params])    create a table
   (table? obj)                      test if obj is a table
   (table-length table)              number of key/value bindings
   (table-ref table key [default])   get value associated with key
   (table-set! table key [value])    set value associated with key

These names follow the same naming convention as vectors.  This
makes it easy to remember the names of the operations.  Note in
particular the "table-length" (equivalent to the proposed
"hash-table-count") and the absence of "table-delete!" (you
get that effect when the third argument of "table-set!" is absent;
I always have a hard time remembering if it is "-delete!" or
"-remove!", etc and with Gambit's interface all mutations of
a table are done with "table-set!" so it is easy to spot in
the code with a grep).

Marc