Okay, I agree.

The attached patch changes the behavior (with the first one doing
a trivial cleanup), and I'd like to improve the documentation further in a separate patch.

Please check.

(file #53051, file #53052)

I'm just a bit reluctant because '-name /' will really only find
a match if "/" is given as starting point (which we don't know at
the time of parsing the expression tree).
In all other cases it is better for a user to keep the simple rule
in mind that the -name pattern must never contain a slash.
Hence to issue a warning is a good thing IMO.

So for my understanding:
if 'find / -prune -name /' boils down to 'echo /', then what is
the real use case behind?

It's true: even a comment in function pred_name_common [1] says that the
name pattern '/' has to match the "/" root file system entry:

Recall that 'find / -name /' is one of the few times where a '/'
in the -name must actually find something.

[1] https://git.savannah.gnu.org/cgit/findutils.git/tree/find/pred.c?id=43679658e2b#n464

The check with the warning is a GNU extension during the parsing of the command line
in function check_name_arg [2], and is therefore not issued with either the -nowarn
option or the environment variable POSIXLY_CORRECT set.

[2] https://git.savannah.gnu.org/cgit/findutils.git/tree/find/parser.c?id=43679658e2b#n1270

Well, we could differentiate if the pattern is a plain "/" and in that
case say something like this:

diff --git a/find/parser.c b/find/parser.c
index c65ae1a8..0562372f 100644
--- a/find/parser.c
+++ b/find/parser.c
@@ -1272,14 +1272,29 @@ check_name_arg (const char *pred, const char *alt, const char *arg)
 {
   if (should_issue_warnings () && strchr (arg, '/'))
     {
-      error (0, 0,
-            _("warning: %s matches against basenames only, "
-              "but the given pattern contains a directory separator (%s), "
-              "thus the expression will evaluate to false all the time.  "
-              "Did you mean %s?"),
-           safely_quote_err_filename (0, pred),
-           safely_quote_err_filename (1, "/"),
-           safely_quote_err_filename (2, alt));
+      if (0 == strcmp ("/", arg))
+       {
+         error (0, 0,
+                _("warning: %s matches against basenames only, "
+                  "but the given pattern equals the directory separator (%s), "
+                  "and hence will only match the file system root entry %s.  "
+                  "Did you mean %s?"),
+                safely_quote_err_filename (0, pred),
+                safely_quote_err_filename (1, "/"),
+                safely_quote_err_filename (2, "/"),
+                safely_quote_err_filename (3, alt));
+       }
+      else
+       {
+         error (0, 0,
+                _("warning: %s matches against basenames only, "
+                  "but the given pattern contains a directory separator (%s), "
+                  "thus the expression will evaluate to false all the time.  "
+                  "Did you mean %s?"),
+                safely_quote_err_filename (0, pred),
+                safely_quote_err_filename (1, "/"),
+                safely_quote_err_filename (2, alt));
+       }
     }
 }

This would result in:

find: warning: '-name' matches against basenames only, but the given pattern equals the directory separator ('/'), and hence will only match the file system root entry '/'.  Did you mean '-wholename'?

I personally like to get such a warning, as one should try to use -name/-iname
with patterns for basenames only, and I think that the use case 'find / -prune -name /'
is quite exotic (and I would never have tried it myself TBH), so I'm wondering if it's
worth bothering to improve the warning diagnostic as shown above.