The javalib Files#walkFileTree offers multiple opportunities for improvement (aka defects).
I am doing my best to avoid a philippic.

When the dust settles on walkFileTree, the corresponding walk method should be examined
for similar opportunities.

A non-comprehensive list:

• The way that SN calls postVisitDirectory() does not match JVM.
  In current code, lll the calls are done after the last element of the
  walk is processed. JVM follows the more expected
  "preVisitDirectory, visitDirectory, postVisitDirectory".

• Issue Files.walkFileTree does not throw FileSystemLoopException #3744

• Issue Files.walkFileTree silently swallows NoSuchFileException #3879 Possibly hidden, but not fixed, by PR fix: javalib SimpleFileVisitor#visitFileFailed now matches JVM #3889.
  Later: Issue Files.walkFileTree silently swallows NoSuchFileException #3879 was fixed by PR fix: javalib SimpleFileVisitor#visitFileFailed now matches JVM #3889

• Pessimal algorithmic & runtime performance. At least:

  • Testing for same attributes more than once. The tests
    go all the way out to the file system on each call.
    The JVM doc describes doing the much more reasonable one readAttributes()
    to all the attributes likely to be used at once.

  • Currently creating a directory contents stream sits atop algorithmic cost,
    particularly for large directories. The access is not lazy.
    FileHelpers.list(Path): creates an array which is then converted
    to a stream. Every item is touched even if SKIP_SIBLINGS
    happens. This approach eased initial implementation but can
    be improved by the code light of day.

• code complex far beyond necessity or confidence.