Right, but when you unlink it from your home directory, the file still exists in the git repo. So there is a manual synchronization that must happen between the two directories.

>Right, but when you unlink it from your home directory, the file still exists in the git repo.

That's a feature.

Not when you are looking for a workflow to make dealing with dotfiles faster and more painless. With the current (symlink based) setup, there is a hidden state you must hold in your head or else carefully inspect: the discrepancy between your git repo and your home directory. Maybe you forgot to link a dotfile, and that’s why your latest configuration doesn’t work. Ditto for unlinking a dotfile.

Isn't that what -D, -S, and more simply -R do?

I did not use stow 2.x, but my understanding is that running stow -R will allow you to remove previous dangling symlinks (during the unstow) and add missing symlinks (during the restow). Effectively allowing you to only manage a single state: your git repository.

I delete dotfiles so infrequently (once a year?) that this just isn't a problem for me.

I also don't have all dotfiles under version control, just the ones I've essentially "built myself", so maybe that makes it easier.

`git rm` will still leave the file available in the repo history, so violating the consistency seems more like a bug than a feature.

Still a feature. You might want to revert back to it. And history is history.