bug#71264: 30.0.50; Dired deletion moves point under auto-revert

[Eli Zaretskii <eliz@gnu.org>]

> From: "Basil L. Contovounesios" <basil@contovou.net>
> Cc: Manuel Giraud <manuel@ledu-giraud.fr>,  71264@debbugs.gnu.org
> Date: Sun, 02 Jun 2024 16:59:55 +0200
> 
> Eli Zaretskii [2024-06-01 20:59 +0300] wrote:
> 
> >> Cc: 71264@debbugs.gnu.org
> >> Date: Sat, 01 Jun 2024 19:19:12 +0200
> >> From:  Manuel Giraud via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >> 
> >> I don't know how to prevent this yet.
> >
> > I'm not sure I understand why we need to prevent that.
> 
> I encounter this most often in my homedir: it contains ~140 subdirs and
> files, meaning BOB and EOB are separated by ~2 pagefuls.  Files are
> sorted by name in groups: subdirs first, then dotfiles, then the rest.
> Each time some program, such as a screenshot application, stores a file
> in my homedir, it appears near EOB.  And each time I delete such a file,
> I lose my current position and have to scroll down 2 pagefuls again.
> 
> I understand that auto-revert-mode can come with limitations, but I
> don't think this UX is right, and I imagine Dired can do better.

Maybe I misunderstood what was meant by "this" in "how to prevent
this".  The preceding text was:

> It seems to me that the 'y-or-n-p' call gives the opportunity of a time
> window for the dired buffer to be reverted.  But then, when this revert
> happen the file "foo" has already disappeared so it cannot be found and
> the point ends up at the BOB.

So which part of this did Manuel want "to prevent"?  That y-or-n-p
doesn't block file notifications is AFAIU by design, and preventing
that could cause much more serious problems.  What I don't understand
is two things:

  . why the fact that "foo"s buffer was reverted affects Dired, and
    what is expected from Dired when a file and its buffer are deleted?
  . why the effect is to move point to BOB?