bug#48621: 28.0.50; UI inconsistency in `find-file-at-point` with respect to `ffap-newfile-prompt`

[Daniel Mendler]

I am using the following configuration for `find-file-at-point`, where I
am request confirmation for new files, for both ffap and plain
`find-file` by setting `ffap-require-prefix=t` and
`confirm-nonexistant-file-or-buffer=t`.

(global-set-key "\C-x\C-f" #'find-file-at-point)
(setq ffap-newfile-prompt t
      confirm-nonexistant-file-or-buffer t)

There is a minor UI inconsistency using this setting:

(1) Press "C-u C-x C-f" (find-file is used) and enter a non-existing
file name. The confirmation mechanism of `completing-read` is used and
shows the message "[Confirm]".
(2) Press "C-u C-x C-f" (find-file-at-point is used) and enter a
non-existing file name. Ffap uses its own confirmation mechanism showing
the message "File does not exist, create buffer?".

In case (2) ffap should also use the confirmation mechanism of
`completing-read` for consistency. This requires setting the MUSTMATCH
argument to 'confirm in the call to `read-file-name` if
`ffap-newfile-prompt` is set and otherwise use the return value of
`(confirm-nonexistant-file-or-buffer)`.

Then the additional `y-or-n-p` prompt implemented in
`find-file-at-point` can be removed. Furthermore the variable
`ffap-newfile-prompt` should be deprecated given the existence of
`confirm-nonexistant-file-or-buffer`. I assume `ffap-newfile-prompt`
predates the introduction of `confirm-nonexistant-file-or-buffer`?

In GNU Emacs 28.0.50 (build 12, x86_64-pc-linux-gnu, GTK+ Version
3.24.5, cairo version 1.16.0)
 of 2021-05-23 built on projects
Repository revision: 04e7c6da34df6b60e253a35b9baa3eba4062617f
Repository branch: icomplete-affixate
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)