Re: "whether the global keymap C-x 4 will be replaced by a command,"

[Stefan Monnier]

>>> Then it could bind `overriding-terminal-local-map` (instead of using
>>> `set-transient-map`)
>> Not sure what's the difference.
> It could simplify implementation of commands that need to modify more 
> variables,
> e.g. both `overriding-terminal-local-map` and 
> `display-buffer-overriding-action`.

You mean you're interested in providing a generic way to "set some vars
for the next command"?  I can see why you'd want that, but:
- It's not as uniform as it seems: `overriding-terminal-local-map` needs
  to be set while "reading" the next command but not while running it,
  whereas `display-buffer-overriding-action` needs to be set while
  running the next command and not while reading it.  
- `set-temporary-map` doesn't need to just "set" the var: it needs to
  modify it and then revert the modification (and handle the case where
  some other modification took place in the mean time).  IOW we need
  some way to "add" and "remove" something from that var.  Now, that
  probably applies to other vars, so it would indeed be good to provide some
  more generic support for that.

>> This sounds like it might benefit from using a trick like the one I use
>> in `mule-cmds--prefixed-command-pch` in order to let-bind
>> `coding-system-for-read/write` around the call of the next command.
>
> It's surprising that such trick works without problems.  And it seems it's 
> exactly
> what is needed for `project-switch-project`.  I could try to generalize it
> to support modification of arbitrary variables.

Beware: let-binding a var like that can lead to undesired results if the
command run within the let-binding wants to modify this var (the
modification is typically lost) or make it buffer-local (the temporary
let-bound value may "leak" outside of the let-binding).  IOW, some such
variables want to be let-bound but others prefer to be `setq`.


        Stefan