bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory

[Dmitry Gutov <dmitry@gutov.dev>]

On 20/08/2023 20:20, Juri Linkov wrote:
>> +(defcustom project-file-name-history-relativize nil
>> +  "If non-nil, paths in `file-name-history' are adjusted for the current project.
>> +
>> +When non-nil and in `project-find-file' or `project-find-dir',
>> +paths in `file-name-history' are adjusted to be relative to
>> +whatever the current project is, instead of the project which
>> +added those paths.  This only affects history entries added by
>> +earlier calls to `project-find-file' or `project-find-dir'.
>> +
>> +When `project-read-file-name-function' is
>> +`project--read-file-cpd-relative' (the default), this has the
>> +effect of sharing more history between projects.")
> Instead of, or in addition to 'project-file-name-history-relativize',
> another option may be needed to define whether to check the
> existence of the constructed file name.  This could help
> to filter out irrelevant file names constructed from
> different projects.

It could indeed. But it could also prevent the user from easily creating 
a new file with the name from a "sister" project.

We've discussed this before in this thread, including the idea of some 
predicate checking the projects for compatibility, etc. What behavior 
would you actually choose yourself?