Thanks for the suggestion.

First of all, despite I'm using the shell quite a lot, I've never used the
"@(...)" notation myself.

The POSIX specification [1] is quite clear about the pattern matching of the
-name option:

-name  pattern
    The primary shall [...] using the pattern matching notation described in
    Pattern Matching Notation.  The additional rules in Patterns Used for
    Filename Expansion do not apply as this is a matching operation, not an
    expansion.

The "Pattern Matching Notation" [2] in turn only foresees the question mark '?',
the asterisk '*' and the left square bracket '[' as special characters with a
special meaning.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13

Therefore, adding the FNM_EXTMATCH flag to the standard -name/-iname options is
impossible.  Furthermore, changing the behavior would/could break existing
scripts relying on the specified pattern matching.

Regarding adding another option for FNM_EXTMATCH:

The fnmatch(3) manual page states that FNM_EXTMATCH is a GNU extension.
Luckily, the gnulib module findutils is pulling in - fnmatch-gnu - supports that
flag.
OTOH, find(1) already supports the -regex option as GNU extension with several
modes (as defined by -regextype) which allow alternative pattern matching,
e.g. with the standard regex mode:

$ find . -regex '.*?\(mp4\|avi\|mov\)$' -print -quit
./hayseed_dixie/hayseedstory.mov

As no-one else voted for the FNM_EXTMATCH feature at all, I therefore think that
the given -regex functionality seems to be sufficient; and introducing yet
another way to specify file name patterns may possibly confuse the users more
than it helps.
I'm therefore changing the severity to 'wish'.

Still, I believe improving the documentation to clarify the behavior is always
worthwhile - suggestions and patches welcome.

Have a nice day,
Berny