It looks like the bug occurs when "mychanges" (as in
"tla undo -o mychanges") is located in the working directory
itself, as tla will try to "undo" it.

A proper solution would be to use a temporary name in any
case, then move the result in the proper place.

Reproduction:
1. cd into your working tree
2. Make changes to your source. Change files and add files.
3. tla undo -o mychanges (really "mychanges", not ",,mychanges")

Expected result:
Clean working tree (as in archive), plus a changeset dir called "mychanges"

Actual result:
Seems like tla undo records mychanges as "change/addition" of the working dir and in the end decides to delete it. Duh.

Symptoms:
- tla barfs with
Error calling `vu_stat' for "/path/to/working/tree/mychanges/patches/./path/to/changed.file.patch" (No such file or directory)
- Your added files have already been deleted.
- There is no "mychanges" dir
- There are 2 dirs, called ,,tmp-*. One of them contains lots of numerical dirs. The dir "0" contained the changeset (complete, it seemed), at least in my case. So, it seems that no data was actually lost, just hard to find.