I don't think this is the same as issue1327.

The problem discussed here has nothing to do with picking the wrong "real" 
ancestor (it always did, in the examples here), it's rather that merge doesn't 
use the ancestor that rebase wants it to use, which might be different from the 
"real" ancestor.

The result is that overlapping changes in the same file occurring in successive 
rebased changesets will generate unnecessary merge conflicts.

I'll reproduce below a very short test case, which I've reported on the mailing 
list last summer (http://selenic.com/pipermail/mercurial-devel/2009-
August/014939.html).

----
hg init testrebasequeue
cd testrebasequeue
echo test > file
hg ci -Am 'initial version, patches will first be on top of that'
echo more data >> file
hg ci -m 'preparing target for rebase'
hg up 0
echo some leading text > file
echo test >> file
hg qnew -f add_first_line
echo some leading line > file
echo test >> file
hg qnew -f modify_first_line
HGMERGE=internal:merge hg rebase --debug --base qbase --dest 1
----

Testing with:

$ hg version
Mercurial Distributed SCM (version 1.3.1+383-6cb1808e5ae7)

(i.e. 27 changesets after f8ca4035a949).

Just before the rebase operation, we have:
----
@  3:[mq]: modify_first_line 9848f5759da7
|
o  2:[mq]: add_first_line 18d95753c96e
|
| o  1:preparing target for rebase b5eff2a0194f
|/
o  0:initial version, patches will first be on top of that f14da50a19b2
----

Rebasing the first patch works, but not the second:
----
...
rebasing 2:18d95753c96e
...
my file@b5eff2a0194f+ other file@18d95753c96e ancestor file@f14da50a19b2
...
rebasing 3:9848f5759da7
...
resolving manifests
 ...
 ancestor 18d95753c96e local b932c6d7da51+ remote 9848f5759da7
...
my file@b932c6d7da51+ other file@9848f5759da7 ancestor file@f14da50a19b2
----

So the correct "rebase" ancestor (18d95753c96e) was found during the "resolving 
manifests" step, but for performing the merge, the "real" ancestor 
(f14da50a19b2) is used.

It's like astratto wrote in msg9727 below:
  actually the ancestor returned by rebasemerge
  is the correct one (the first). The line with my... is returned by filemerge
  that seems to override the modified ancestor with a wrong one (it's the real
  ancestor and we don't need it).

Can we reopen?