> a solution should allow packages to declare that command FOO
> should be bound to some key based on SOME-INFO, such that it will be
> bound to one key in "normal Emacs mode", and to another in `evil-mode`
> and to yet another in `god-mode`, etc...
SOME-INFO will be of the form:
((concept command) (concept command) ...)) ; package provide
((concept (concept concept concept)) (concept concept)) ; overload remappings, perhaps user or package provided or both
((concept binding) (concept binding)) ; user or emulation mode etc provided
The overloads might be embedded in the first and second lists, but it will make for complicated reading later.
Either a built-in implementation in Emacs or customized implementations
in packages should consume the full SOME-INFO and generate keymaps. If that keymap generation is dynamic or the keymap itself embeds indirection for contextual operations, we get essentially dynamic dispatch, and there's not much need for new implementations. emulation-mode-map-alists has its structure for good reason.
In the beginning, before packages provide their half, the user will
provide it, likely through a package. This is analogous to evil
collection.
There likely will not be enough concepts to support relocating every key this way. While the default implementation that ships with Emacs can attempt to rearrange keys usings current behavior and a heuristic where that is not possible, if the user configures a different implementation, even one that ignores the mode's SOME-INFO in part or whole, commands will be unbound. This is good. We have to support the notion that the provided commands are bad and that the users wants to write better ones or else we are choking the evolution of the interaction models. Package authors should focus on good functions and editing data models. This is what makes it easy to write good commands. Attempting to write all the good commands is not possible without lots of user representation, which package authors cannot individually have.