Yes, a leading `**' is special-cased, for zsh compatibility. That was the only special-casing concession I made, so it matches everywhere else in a pattern. If you find other cases, please let me know.

The leading `**' thing was specifically pointed out as a bug/incompatibility with zsh (the only other implementation worth considering; the ksh93 one is too buggy).

zsh treats ./** the same as **; for me, that was a step too far.

Starting in Bash 4.3, globstar `**` patterns no longer walk indefinitely down recursive symbolic links.  This is very good!

However, I noticed a curious change in how this is implemented, which appears to start with (at least) Bash 5.1.

Reproduction:

$ mkdir -p a/symlink/a/b; ln -s ../.. a/symlink/a/b/c

$ tree a
a/
└── symlink/
    └── a/
        └── b/
            └── c -> ../../

4 directories, 0 files

$ ./bash -O globstar -O extglob -O nullglob -c 'for i in **/a/**/ ; do echo $i; done | sort | uniq'
a/
a/symlink/
a/symlink/a/
a/symlink/a/b/
a/symlink/a/b/c/

$ ./bash -O globstar -O extglob -O nullglob -c 'for i in ./**/a/**/ ; do echo $i; done | sort | uniq'
./a/
./a/symlink/
./a/symlink/a/
./a/symlink/a/b/
./a/symlink/a/b/c/
./a/symlink/a/b/c/a/
./a/symlink/a/b/c/a/b/
./a/symlink/a/b/c/a/b/c/

$ ./bash --version
GNU bash, version 5.2.0(5)-alpha (aarch64-apple-darwin21.3.0)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

A symbolic link points from `a/symlink/a/b/c` to `a/symlink`.  I would expect that the first `**` matches as far as `a/symlink/a/b/c`, but does not descend to child paths.  Then the `a` matches `a/symlink/a/b/c/a`.  The second globstar matches `.../b/c`, but does not descend further, as `c` is a symlink, resulting in `a/symlink/a/b/c/a/b/c` appearing in the results.

This is what happens if the pattern starts with a non-globstar portion, including `./`, as shown here.  This is also what happens when using `**/a/**/` in Bash 4.3.  However, in Bash 5, with a pattern starting with `**` not preceded by any other non-globstar pattern portion, it seems to not allow `**` to match any child paths of the symlink target, even if the `**` matches the symlink, and literal (existing) path portions follow it.

Placing a `./` in the pattern can show what the `**` is matching:

$ ./bash -O globstar -O extglob -O nullglob -c 'for i in **/./a/** ; do echo $i; done | sort | uniq'
./a
./a/symlink
./a/symlink/a
./a/symlink/a/b
./a/symlink/a/b/c
a/symlink/./a
a/symlink/./a/b
a/symlink/./a/b/c

$ ./bash -O globstar -O extglob -O nullglob -c 'for i in ./**/./a/** ; do echo $i; done | sort | uniq'
././a
././a/symlink
././a/symlink/a
././a/symlink/a/b
././a/symlink/a/b/c
./a/symlink/./a
./a/symlink/./a/b
./a/symlink/./a/b/c
./a/symlink/a/b/c/./a
./a/symlink/a/b/c/./a/b
./a/symlink/a/b/c/./a/b/c

I maintain a glob implementation in JavaScript, which aims to match Bash's path expansion behavior exactly, so this threw a little bit of a curve ball at me.  If this is intended behavior, it would be good to know the specific conditions where `**` will not match a against symlink (even when child paths are specified literally).  If it is unintended behavior, then I can continue to model Bash 4.3 expansion behavior, and just include it as a caveat in my docs.

Thank you for all your work on Bash over the years.  It's such a lovely shell, and I still enjoy it every day.