Actually, what it works with is a partially sorted input: an input in some tree-order input, which is what any recursive file system traversal will always put out. It will work with depth first or breadth-first order, with usefully different results, and that order preserved.

All it is doing is hiding the redundancy with spaces to improve the human readability of find's output.

Here it is on the same data in breadth-first. Note the lack of any lexicographic sort: "interfaces" is flanked by "if-down.d" and "if-pre-up.d":

  /etc/network
              /if-post-down.d
              /if-down.d
              /interfaces.d
              /interfaces
              /if-pre-up.d
              /if-up.d
              /if-post-down.d/wireless-tools
                             /wpasupplicant
                             /avahi-daemon
              /if-down.d/resolvconf
                        /wpasupplicant
                        /avahi-autoipd
              /if-pre-up.d/wireless-tools
                          /wpasupplicant
                          /ethtool
              /if-up.d/ntpdate
                      /wpasupplicant
                      /000resolvconf
                      /openssh-server
                      /ethtool
                      /avahi-autoipd
                      /slrn
                      /avahi-daemon

My first program in TXR Lisp in the grandparent comment builds the tree structure from the paths in any order and then prints that, so the paths could be scrambled into random order, yet it will recover the tree structure.

However, not munging the the output in that way and just tweaking the original output for readability has some advantages