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

[Juri Linkov]

>> 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`.

>> and also bind `display-buffer-overriding-action`
>> (instead of using `display-buffer-override-next-command`).
>
> Neither do I understand what's better about "bind
> `display-buffer-overriding-action`" compared to using
> `display-buffer-override-next-command`.

For simplicity as well.  And for uniformity of modifying the environment
of the next command the same way for different variables.

>> This will also solve the problem of setting `default-directory`
>> for `C-x p p` (project-switch-project).  As explained in
>> https://debbugs.gnu.org/41890#196
>> currently it's not possible to bind the value of `default-directory`
>> for the next command, but with a closure the variable binding will have
>> the effect during the next command.
>
> 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.