I think this is a general problem with rebase, not specific to 'merge --
rebase'.  It's annoying: if my current cset (first parent of working dir) is 
A and I run "hg merge B", then I get A=local and B=other.  But if I rebase A 
onto B, the relationship is backwards.  At the level of file merges, merging 
B with A should be the same as rebasing A onto B.

This was with hg 1.4.1.

This is due to the fact that rebase first updates to 'target' and then
merges it with the branch that's to be rebased.

i.e., Given repo1 and repo2
Repo1:
 a - b

Repo2:
 a - c

hg pull --rebase in Repo2 means:
1 - pull b and we obtain:
 a - b
  \
   c

2 - rebase c onto b, that is "update to b and merge with c". Hence, b
becomes the 'local' revision.

What hg version do you have ?

When using merge=internal:merge, merge conflicts in an hg pull --rebase are
labeled incorrectly.  The chunk local to the current repository is labeled
"other", and the chunk from the remote repository is labeled "local".

Steps to reproduce:

~$ mkdir repo1
~$ cd repo1
~/repo1$ hg init
~/repo1$ echo 'ABC' > file
~/repo1$ hg add file
~/repo1$ hg ci -m "file contains ABC"
~/repo1$ cd ..
~$ hg clone repo1 repo2
~$ cd repo2
~/repo2$ echo '111' > file
~/repo2$ hg ci -m "file contains 111"
~/repo2$ cd ../repo1
~/repo1$ echo '222' > file
~/repo1$ hg ci -m "file contains 222"
~/repo1$ cd ../repo2
~/repo2$ hg pull --rebase
pulling from /home/jlebar/repo1
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
merging file
warning: conflicts during merge.
merging file failed!
abort: fix unresolved conflicts with hg resolve then run hg rebase --continue

~/repo2$ cat file
<<<<<<< local
222
=======
111
>>>>>>> other