ln -s link link is a symbolic link loop.  You can't dereference this link at all:

$ ln -s link link
$ stat -L link
stat: cannot statx 'link': Too many levels of symbolic links
$ cat link
cat: link: Too many levels of symbolic links
$ ls -L link
ls: cannot access 'link': Too many levels of symbolic links

ln -s . link is not a symbolic link loop!  You can dereference it:

$ ln -s . link
$ stat -L link
  File: link
  Size: 904             Blocks: 0          IO Block: 4096   directory
Device: 0,44    Inode: 18767458    Links: 1
Access: (0750/drwxr-x---)  Uid: ( 1000/tavianator)   Gid: ( 1000/tavianator)
Access: 2024-09-09 09:37:16.795319268 -0400
Modify: 2024-09-09 09:37:16.935322293 -0400
Change: 2024-09-09 09:37:16.935322293 -0400
 Birth: 2021-06-30 14:48:16.026406491 -0400
$ ls -L link
ABOUT-NLS
AUTHORS
COPYING
...
link
...

Find reports an error for this kind of loop because otherwise it would never stop printing link, link/link, link/link/link, etc.  But that's different from the first kind of loop, so the different error makes sense.

The issue

In case of loops, find prints a different error message depending on if a loop includes:

• either: only symbolic links
• or: at least one directory

    
length = 1:

$ ln -s link link
$ find -L -xtype l
find: ‘./link’: Too many levels of symbolic links
$

length = 2 / two symbolic links:

$ ln -s symb link
$ ln -s link symb
$ find -L -xtype l
find: ‘./link’: Too many levels of symbolic links
find: ‘./symb’: Too many levels of symbolic links
$

length = 2 / one symbolic link and one directory:

$ ln -s . link
$ find -L -xtype l
find: File system loop detected; ‘./link’ is part of the same file system loop as ‘.’.
$

Having two different error messages implies that find somehow interprets these loops differently (and that the user must know the difference and must adjust their command line consequently).

If find does process these loops differently (meaning: find requires an adjustement on the command line (input), or will produce a different result (output) in some specific cases), then it should be explained in the GNU Findutils manual in section "2.4.1 Symbolic Links" where the only reference on this subject (explaining that both are treated identically) is:

• "This also occurs if a symbolic link exists but points to a file that is missing [broken link], or where the symbolic link points to itself [loop] (directly or indirectly)."

If find processes these loops identically, then there should be only one type of error message. The message "File system loop detected […]" should be chosen, being more useful due to:

• properly explaining that it is an actual loop and not simply a number of links (not forming a loop) exceeding some hard-coded maximum level of indirection
• providing the start and the end of the loop

This difference or equality of treatment should also be referred to in section 12.1 Error Messages From find.

This may not seem important, however:

• If the user grep-s the standard error of find to filter some error messages (see this example), two different error messages for one error is, for the user, more work for nothing more to gain.
• When testing some options of find, it is more work to assert that link-to-link loops and link-to-directory-to-link loops produce an identical result (these extracts above are from my own personal test trying to understand "-L -xtype l" depending on {broken | link-to-self | link-to-link | link-to-directory-to-link | normal}).
• It may have an impact on bug reporting. (see below)
• It may have an impact on web searches: requesting help using one error message might not result in a solution provided by a forum to the same problem but raised by another error message.

Concrete case of bug reporting

According to bug #65831, the following example is a bug concerning link-to-link loops:

$ ln -s link link
$ find -L -type l
find: ‘./link’: Too many levels of symbolic links
$ echo $?
1
$

I quote: "The exit status is 1. Nothing is printed on stdout."

But this bug says nothing on this following link-to-directory-to-link loop:

$ ln -s . link
$ find -L -type l
find: File system loop detected; ‘./link’ is part of the same file system loop as ‘.’.
$ echo $?
1
$

Same result: The exist status is 1. Nothing is printed on stdout.

However, the error message is different. Should it be considered a variation of the same bug, or should a different bug report be filed? A user who does not know that both error messages are the same error (after all, they are not even documented on the 12.1 Error Messages From find), and even going the extra mile of checking that their bug has not already been reported, may not find the previous bug due to the error message being different.