No, it's not fixed.  I've identified at least one place where catching ENOENT helps ...

diff --git a/find/ftsfind.c b/find/ftsfind.c
index 0d96c4ca..6aeac28c 100644
--- a/find/ftsfind.c
+++ b/find/ftsfind.c
@@ -401,6 +401,10 @@ consider_visiting (FTS *p, FTSENT *ent)
            }
          else
            {
+             /* Ignore unlink() error for vanished files.  */
+             if (ENOENT == ent->fts_errno && options.ignore_readdir_race)
+                 return;
+
              nonfatal_target_file_error (ent->fts_errno, ent->fts_path);
              /* Continue despite the error, as file name without stat info
               * might be better than not even processing the file name. This

..., but there seem to be more.
Here, the reproducer in #4 still "works".

The issue can be triggered with a shorter command line.

Run this in one terminal:

while env true; do sleep .001; done

and in another one this find(1) command:

$ find /proc -ignore_readdir_race -maxdepth 3 > /dev/null

With that, find(1) is hitting the error pretty reliably.

FWIW: Interestingly, 'oldfind', i.e., the old non-FTS implementation even runs into an endless loop:

...
/home/berny/findutils/find/oldfind: ‘/proc/1143/net’: Invalid argument
/home/berny/findutils/find/oldfind: ‘/proc/1143/net’: Invalid argument
/home/berny/findutils/find/oldfind: ‘/proc/1143/net’: Invalid argument
/home/berny/findutils/find/oldfind: ‘/proc/1143/net’: Invalid a^C

I can confirm the issue with CentOS7. Package info: findutils-4.5.11-5.el7.x86_64

Have a CRON that runs on multiple machine at the same time. Part of the script remove old log file in a common NFS folder.
It uses 'find' for this and checks the file timestamp (mtime)

It's pretty much guaranteed to get into a race condition with  this specific setup (NFS mount..).

Using -ignore_readdir_race does not seem to have any effect.

We have a cron job that is used to clean cache directories. There's a log going on in that directory, especially files getting moved from temporary names to their final names after they have been written completely. We have noticed that the find that is supplied with Centos7 (version 4.5.11) as well as a find 4.5.14 built from unmodified source frequently prints "No such file or directory" errors for the initial filenames of the temporary files, despite the fact that we have specified -ignore_readdir_race, e.g.:

/usr/bin/find: ‘./engine/projects/portal/istmp1NYV9b’: No such file or directory

This does not happen with a find 4.4.2 compiled from source. A trivial find in the "busy" directory is sufficient to triffer the error message almost 100% of the time:

find . -ignore_readdir_race > /dev/null