Re: Making a key undefined again

[Gregory Heytings]

> > but that breaks when `foo-next-thing' is renamed to `foo-forward'. And 
> > even if that never happens, it still complicates `foobar-mode-map', 
> > which now has a binding for `foo-next-thing', which isn't actually 
> > necessary because an identical binding exists in the parent keymap 
> > `foo-mode-map'.
>
> How common is this case?
>
> So your notion of "no binding at all" can also be described as something 
> like "use the binding of the parent".

This happens because t is stored in the keymap when using (define-key ... 
nil), as explained in store_in_keymap():

Faset (elt, idx,
       /* nil has a special meaning for char-tables, so
          we use something else to record an explicitly
          unbound entry.  */
       NILP (def) ? Qt : def);

Would it not be possible to add another value that would actually be be 
stored as a nil at that point, for example 'nil / QQnil?