Re: function-key-map

[Richard Stallman]

    Renaming input-decode-map to function-key-map would be a bad idea because it
    would introduce an incompatibility: the behavior of input-decode-map is
    different, so while some uses of function-key-map are better moved to
    input-decode-map, others (such as the ones mentioned at the beginning of
    this message) need to stay on function-key-map.

Ok.

      Actually the name
    function-key-map would also be bad because it would fail to describe what
    the map does (and instead describes what it was meant for).

That is not necessarily a bad thing, but this map is not solely for
producing function keys.  So lt's stay with `input-decode-map'.

    Renaming function-key-map to `default-key-translation-map' would also seem
    like a bad idea:
    - the name seems to imply that it's the global binding of "the
      buffer-local key-translation-map".
    - the name suggests the behavior of that map will be the same as the 
behavior
      of `key-translation-map' although in reality it is different.

Those are valid arguments against the name `default-key-translation-map',
but not against renaming to a different name.

    Right now, in the term/*.el files that I've changed to take advantage of
    input-decode-map, I've used "foo-alternative-maps" for the keymaps that
    hold bindings that need to be added to function-key-map, so maybe we could
    rename function-key-map to alternative-input-names-map or
    fallback-input-rename-map?

"Alternative" does not clearly describe the functionality, but
"fallback" does.  (I used "default" for the same meaning.)

So how about `key-fallback-alias-map'?