Scheme does a great job masking the distinction between "object" and
"non-object" types as other languages would call them.  Only eq?
somewhat leaks the distinction.  Now in SRFI-126 there are also weak
hashtables which could leak that distinction.  I think it's best to mask
it as much as possible.

Therefore the next draft of SRFI-126 will contain the following prose in
the introduction of the specification (which is an amended and clarified
version of what was previously found under make-eqv-hashtable's spec):

***

Booleans, characters, numbers, symbols, and the empty list object are
never stored weakly or ephemerally.

*Rationale:* Objects of these types can be recreated arbitrarily, such
that a new instance is equivalent (as per `eqv?`) to a previous
instance, even if the previous instance was deallocated and the new
instance allocated freshly.  Therefore objects of these types must be
considered alive at all times even if no references remain to them in
a program.

***

This means that if you (hashtable-set! weak-key-table 'foo object), you
will keep 'object' alive until either the weak-key-table is GC'd, or you
clear or change the association for the symbol foo.

Does anyone have objections from a language semantics perspective?  To
me it seems like the right thing to do.  'foo is always 'foo, no matter
how many times it was garbage collected and recreated, so you don't want
your association for it dropped at some point.  Same with characters and
numbers.

But another problem might be implementation.  I haven't ever implemented
weak hash tables--up until now SRFI-126 simply took the semantics from
MIT/GNU Scheme so that was fine.  I need input on whether I'm specifying
something that would be a burden to implement and whether it would be
better to leave some behavior unspecified here.

Thanks in advance,
Taylan