Actually, the failure when '.' can't be found (for example, because a parent is unsearchable) was introduced in 4.3.3; I'll open a separate report for that.

This report deals with unreadable, but searchable parents.  Indeed, fts makes a difference:

$ mkdir -p private/d
$ touch private/d/a
$ ~/findutils-4.3.8/find/find /tmp/private/d
/tmp/private/d
/tmp/private/d/a
$ chmod a-rw /tmp/private
$ ~/findutils-4.3.8/find/find /tmp/private/d
/tmp/private/d
/tmp/private/d/a
$ ~/findutils-4.3.8/find/oldfind /tmp/private/d
/home/ericb/findutils-4.3.8/find/oldfind: `/tmp/private': Permission denied

At this point, since we are about to create a stable 4.4 branch where the fts()-based find works, do we still need to worry about the home-grown oldfind, which still has the bug?

And do we go ahead and add the patch attached to this bug to the 4.3.x testsuite, when it will only pass on one of the two implementations?

I can't immediately think of any other way to ensure that -execdir will securely succeed other than to chdir() to the parent directory.  Where the start point is a direcotry you could chdir() to that and use "." but that workaround won't be good for a plain file.