I can’t speak to the implementation but in principle, a filesystem essentially being a specialized database, there’s no reason techniques commonly used for SQL optimization couldn’t be applied here. It’s fundamentally set theory, where you’re obtaining your results by producing subsets rather than traversing a hierarchical tree of branches and end nodes. Of course that implies some pathological conditions (some superset/subset scenarios will produce too many results to be useful or to optimize resolution) which would produce poor UX, but sane defaults and heuristics could alleviate that.

Again not speaking to the project itself, but in principle achieving good performance on something like this would boil down to “do what SQL databases do, then design efficient schemas and queries for the use case”.

Not formally, no, but anecdotally, I do notice some performance impact with with many files and tags, and some of the more aggressive file browsers like to depth-first cache directories, which can be involved when directories are generated dynamically and extremely deep. I am actively looking for solutions to that!

Fortunately you can try Supertag out without touching your original files, as Supertag will use symlinks to your original files, so you don't need to move them.

You should only use raw block number instead of filesystems this way you would get even better performance /S