My KaOS root partition no longer boots after a failed system update. I ran pacman -Syu as usual and the packages all downloaded. Errors occurred during the upgrade stage. Here are the last few lines of the terminal output:

( 9/379) upgrading filesystem [-------------------------------] 100%
error: extract: not overwriting dir with file /usr/local/share/man
error: problem occurred while upgrading filesystem
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.

At this point, already running applications still functioned (allowing me to copy and save the above output), but I could not launch any new applications. After reboot, the system hangs during the initial TTY phase (before the display manager normally starts) with several [failed] starting *** messages.

Is there anything I can do to salvage the installation or do I need to reinstall from the latest iso?

(I’m not worried about data loss -- all my data is on a separate partition.)

First a full pacman.log will be needed from this failed upgrade. Log is at /var/log/pacman.log, you can get it a couple of ways. One is to use any Live ISO and navigate to that directory.
But since you will have to chroot anyway to fix this install, use this guide:
https://kaosx.us/docs/chrooting/

Still, try to give as much info as possible how you got to this, and especially how you got to have issues with /usr/local/share/man, a directory owned by the filesystem package on KaOS.
https://kaosx.us/docs/

Below are the most recent /var/log/pacman.log entries (all other entries are at least 2 weeks old):

[2019-01-12 19:15] [PACMAN] Running '/usr/bin/pacman -Sy'
[2019-01-12 19:15] [PACMAN] synchronizing package lists
[2019-01-12 19:25] [PACMAN] Running 'pacman -Syu'
[2019-01-12 19:25] [PACMAN] synchronizing package lists
[2019-01-12 19:25] [PACMAN] starting full system upgrade
[2019-01-12 19:31] [ALPM] transaction started
[2019-01-12 19:31] [ALPM] upgraded tzdata (2018g-1 -> 2018i-1)
[2019-01-12 19:31] [ALPM] upgraded gcc-libs (7.3.1-2 -> 7.4.0-1)
[2019-01-12 19:31] [ALPM] upgraded coreutils (8.30-1 -> 8.30-2)
[2019-01-12 19:31] [ALPM] upgraded perl (5.26.2-2 -> 5.28.1-1)
[2019-01-12 19:31] [ALPM] upgraded openssl (1.0.2.17-1 -> 1.1.1.1-1)
[2019-01-12 19:31] [ALPM] upgraded mariadb (10.1.37-1 -> 10.1.37-2)
[2019-01-12 19:31] [ALPM] upgraded libffi (3.2.1-5 -> 3.2.1-6)
[2019-01-12 19:31] [ALPM] upgraded glib2 (2.56.2-1 -> 2.58.2-1)
[2019-01-12 19:31] [ALPM] error: problem occurred while upgrading filesystem
[2019-01-12 19:31] [ALPM] upgraded filesystem (2018.01-2 -> 2019.01-1)
[2019-01-12 19:31] [ALPM] transaction failed

I think I probably got to having issues with /usr/local/share/man as a result of installing an application from a tar.gz file. This happened once before when I installed pandoc (a command-line document format converter). It appears that certain files get placed in /usr/local/share/man as a result of the installation. The first time it happened I solved the problem by simply deleting /usr/local/share/man and rerunning the system upgrade. Unfortunately, for this more recent system update, I forgot about that previous solution and attempted to reboot immediately after the upgrade failed, leaving me with an unbootable system.

(I obtained the pandoc tar.gz from github and installed it as per the instructions there -- I realize this may not be officially supported and I did it at my own risk.)

As you note now, never install any in the root filesystem outside of the packagemanager, make sure to always use PKGBUILD/makepkg:
https://kaosx.us/docs/package/
But this issue should not be hard to solve, chroot into the system, delete all of pandoc, then try to update again. If that fails, try to first just install the new filesystem package. If that still fails then force will be needed, so yes, might be needed again to delete /usr/local/share/man.

Yes, I realize I made a big mistake. Presumably, though, there is nothing wrong with installing from a tarball to /home. For example:

$ tar xvzf /PATH/pandoc-2.3-linux.tar.gz --strip-components 1 -C ~/.local/

Does makepkg offer any advantages over this?

What you do in your home directory will never affect system updates
Advantages of always using makepkg/PKGBUILD

  • All files are installed by the package are always tracked by pacman, you never have to guess where a file came from
  • Installs will be system wide, accessible by all users, not just your user
    *Ease of use of the application, menu entry will be available, all linking is done according to the filesystem, no need to set paths.

OK, I have successfully chrooted into KaOS and deleted the pandoc files inside /usr/local/share/man
But I cannot run pacman in chroot:

# pacman -Syu
pacman: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

Such an error would suggest that I need to specify additional library paths with export LD_LIBRARY_PATH= but I am not sure. I cannot find libcrypto anywhere under KaOS root.

Your failed update was in the middle of the huge openssl update.....
All was rebuild to use libcrypto.so.1.1.0, anything that linked against libcrypto.so.1.0.0 needed a rebuild to link against the new version. Seems your partial update did get the new openssl, but not all the packages (like pacman) that were rebuild.
For now, best option is to get libcrypto.so.1.0.0 from your cache /var/cache/pacman/pkg/openssl-1.0.2.17-1-x86_64.pkg.tar.xz, extract that tar, then copy the libcrypto.so.1.0.0 & libssl.so.1.0.0 to /usr/lib, then update, after the update is done, remove those 2 libs again.
If you don't have that version of openssl in your cache, let me know, I can upload it somewhere.

The system is now successfully restored. A regular pacman -Syu wasn't enough. I had to reinstall all packages with:
pacman -Sy $(pacman -Q | cut -d " " -f1 | grep -v "$(pacman -Qm | cut -d " " -f1)")