I believe that removing the fseventsd directory in single-user mode is unnecessary. Simply booting into single-user mode caused a deep traversal for me. (I'm not sure if you have to mount your root filesystem read-write; I did.)

Booting in single-user mode may cause a deep traversal. It did for me once, but not subsequent times. Deleting /.fseventsd definitely will. It should be safe to do this in single-user mode. Deleting /.fseventd on the backup volume did not trigger a deep traversal for me. (My system continued on as normal and never even re-created it.)

tmutil compare is only somewhat accurate. It seemed to accurately identify files that were not backed up at first. I triggered a deep traversal to correct this, but Time Machine is still not backing up many files. Yet tmutil compare now claims that there isn't a problem. I would trust:

rsync --dry-run --itemize-changes --checksum --protect-args -aNHAXx --protect-decmpfs --fileflags --force-change --delete path/to/source_dir/ path/to/destination_dir/

Use /Volumes/<your time machine volume>/Backups.backupdb/<your machine name>/Latest/ as either the source or destination path. --itemize-changes lets us see what is different; '--checksum' tells rsync to actually compare file contents, rather than just modification times and file size; and --dry-run tells rsync not to actually backup (so it just tells us what it would do). The rest of the arguments are flags telling rsync to make the destination identical to the source in every way, including metadata and HFS compression status. I believe that Time Machine adds bookkeeping metadata which it removes when restoring, so rsync may find spurious metadata changes.