works for me, too.

Matt, it looks like the dirstate.changes rewrite fixed this:
tonfa@arakou /tmp/xxxxx/truc $ hg init
tonfa@arakou /tmp/xxxxx/truc $ hg commit -A -m m
adding a
tonfa@arakou /tmp/xxxxx/truc $ hg status
tonfa@arakou /tmp/xxxxx/truc $ hg rm a
tonfa@arakou /tmp/xxxxx/truc $ hg status
R a
tonfa@arakou /tmp/xxxxx/truc $ touch a
tonfa@arakou /tmp/xxxxx/truc $ hg status
R a
tonfa@arakou /tmp/xxxxx/truc $ hg ci -m m
tonfa@arakou /tmp/xxxxx/truc $ hg status
? a
tonfa@arakou /tmp/xxxxx/truc $ hg manifest
tonfa@arakou /tmp/xxxxx/truc $

i cannot reproduce it with this patch (simplify of dirstate changes function):
http://www.selenic.com/pipermail/mercurial/2005-October/005167.html

Hmm. Don't think this is quite the bug I was describing. Here's the message:

Mercurial seems to temporarily lose track of the fact that a file was
just removed if you recreate the file before the removal is checked-in.
Is this behavior correct?

Here is an example:

eric2@thud:~$ touch foobar
eric2@thud:~$ hg add foobar
eric2@thud:~$ hg ci -m"bletch" foobar
eric2@thud:~$ hg status
eric2@thud:~$ hg rm foobar
eric2@thud:~$ ls -l foobar
ls: foobar: No such file or directory
eric2@thud:~$ hg status
R foobar
eric2@thud:~$ touch foobar
eric2@thud:~$ hg status
? foobar
eric2@thud:~$ hg ci
nothing changed
eric2@thud:~$ rm foobar
eric2@thud:~$ hg status
R foobar
eric2@thud:~$

The attached patch fix that. But i don't really think this is a bug, i would
prefer mercurial not to touch files like this.

What was the reason for hg rm to remove the file in the fs ? Couldn't it be an
option ?