They're make a really clear distinction between a build system, and a build support system. The "clean" command falls into build support, and the Tup team would argue this is better served with techniques like "git clean -xdf"
The "make clean" command is not perfect. Even if someone writes this make phase correctly, it may break after you sync new makefile changes on a dirty project dir. What do you do in that case?
And I agree that `make clean` isn't perfect, I think that is what makes the fact that `tup clean` doesn't exist even more annoying. A lot of people recommend including an auxiliary Makefile or script to do the cleaning, but it can never be as good as if `tup` just did it itself since it is aware of exactly what files it as created during the build process.
sqlite3 .tup/db 'select name from node where type=4' | xargs echo rm -f
[1]: https://github.com/gittup/tup/issues/120#issuecomment-64832104tup is in some ways brilliant, and i give it kudos for actually improving on make in many ways (unlike 99% of the make-replacement-hopefuls), but man oh man do i value and prefer software devs with a more user-focused philosophy.
(an excellent example of that would be homebrew, which arguably wasn't anything special from a pure-tech perspective, but had amazingly good product sense/user focus. imagine combining that attitude & ux skills w/ the technical brilliance of tup...)
Every time I have needed to clean a Makefile based project it has been due to imperfections of the build system, i.e. needing to do a full rebuild. In theory (I've never used tup in anger) you should never need to do that with tup because the dependecy gathering is so robust.