>>>>> E.g. would people who customized project-switch-commands to a symbol be
>>>>> okay with not being able to use the other functionality of
>>>>> other-project-prefix?
>>>> Symbolic project-switch-commands is supported by other-project-prefix.
>>>
>>> Yes, and that could be a problem: if I as a user want 'C-x p p' to always
>>> run 'project-find-file', for example (in the other project), but I also
>>> want to be able to sometimes call 'M-x other-project-prefix' (or use
>>> a custom binding) to run an arbitrary command in the other project.
>> With other-project-prefix, users can run 'project-find-file'
>> in another project with just:
>> ```
>> (defun other-project-find-file ()
>>    (interactive)
>>    (call-interactively 'other-project-prefix)
>>    (call-interactively 'project-find-file))
>> ```
>
> Right... but they'd have to define a custom function for any such
> command. I think the idea behind 'other-project-prefix' is that one
> wouldn't have to.

Only one custom function.  Or they can just bind the most used command
to the most easily typed key RET.

>>>>> Or what about the variable project-switch-use-entire-map? I'm not sure
>>>>> about dropping it, at least without notifying about that in the UI somehow.
>>>> project-switch-use-entire-map could be handled in other-project-prefix.
>>>> But is this really needed?  I can't imagine why anyone might want
>>>> to disable keys from project-prefix-map.
>>>
>>> I think if project-switch-use-entire-map is still wanted, we should just
>>> keep these commands separate (the same logic as in the previous paragraph).
>> No problem, project-switch-use-entire-map can be easily supported in
>> other-project-prefix.
>
> I'm not saying it's hard to support it there. But it could make the command
> less useful.

When all global keybindings are available, it's strange to remove
keys from project-prefix-map.  But ok, the patch below supports
project-switch-use-entire-map.

>>> Why not remove that option? Consider the current UI (which looks almost the
>>> same in your latest patch): user types 'C-x p p', chooses the project and
>>> then sees the prompt which only offers the options from
>>> project-switch-commands. They are not informed that any other keys could be
>>> used too. So if we were to change the default behavior, I think this
>>> UI/prompt needs to change, at the very least.
>> Agreed, a better prompt needed.  Maybe with the standard C-h key for
>> help.
>
> Some short version initially, and perhaps a more expanded if the user hits
> 'C-h'.

I tried to use 'help-form' in a new patch, but actually 'C-h' is
quite useless when not using the ad-hoc loop as e.g. in y-or-n-p that
forces to type a limited set of keys.

>>>>> Finally, the current patch drops the loop, so if the user types the wrong
>>>>> key, they will need to repeat the command and choose the project again.
>>>> Indeed, the loop now is the command loop, and maybe it's possible to
>>>> write a hack to set a catch-all in set-transient-map that is not
>>>> finished until a key in the map is typed.  But as with any command,
>>>> if the user types a wrong key sequence, then need to type it again.
>>>> I do this all the time with mistakenly typed keys.  I don't see why
>>>> project keys are the exception.
>>>
>>> Maybe because in the middle of it all you have interacted with Emacs to
>>> choose the other project, and that can be a significant amount of typing?
>> Then for repeating the previously selected project it will be in the
>> history:
>> 'C-x p p M-p'.
>
> Fair point. Still, that's more typing and required one to remember/know
> about M-p.

If 'project-prompt-project-dir' remembered the selected directory
like 'project-current' does, then would be possible to repeat with:
'C-x p p M-n'.

>>>> A different key binding for the commands that do the same thing?
>>>> Only because the new command uses the command loop?
>>>
>>> project-switch-project would continue to show the menu with commands, only
>>> work with them by default, and obey project-switch-use-entire-map, which,
>>> when set to t, would enable other commands from the project keymap, but
>>> only them. All accessible via one character binding. And when
>>> project-switch-commands is set to a symbol, it would only invoke that one
>>> command without additional prompting.
>>>
>>> other-project-prefix would accept all commands but require full key
>>> sequence for the invoked command.
>> And also other-project-prefix will fix such bugs as bug#65558.
>>
>>> Would it add shortcuts to the commands from the project keymap?
>>> Possibly. Any ideas how to inform the user about that?
>> By a different prompt?
>
> Probably. Would you like to propose one? So that I have something to
> compare to, and have something specific to put to the vote as well.

Ok, something like this: