This is how a "standard" Linux filesystem (e.g. ext3) reacts:

# first I create three directories and two empty files:
mkdir aa ; mkdir ab ; touch aa/1 ; mkdir ab/aa ; touch ab/aa/2

# Now I try an "illegal" move command, which I expected to result in a
# "merge" of the two "aa" directories:
vlado@platypus:/tmp(0)$ mv ab/aa/ .
mv: cannot move `ab/aa/' to `./aa': Directory not empty

# Now see what I experience on a hfsplus file system (with Linux 2.6.35) with the same "two file three dir" setup:
vlado@platypus:/daten/tmp(0)$ mv ab/aa/ .
# No error message! But what happened? File "aa/1" disappeared silently:
vlado@platypus:/daten/tmp(0)$ ls aa/
2

Mac OS 10.5 on hfsplus reacts just like Linux on its ext3 file system, when I try to move "aa":
"mv: rename ab/aa/ to ./aa/: Directory not empty"

I reported this issue to HFS maintainer Roman Zippel on June 8, but did not get any reply. He fixed an HFSplus issue reported by me in 2008[1], but in bug #14021 Andrew Morton writes he hadn't heard from Roman since January 2009.

The hfsplus bug #13083 apparently was fixed by Jeff Mahoney, which is why I include him in this bug's CC list.

I'm running a Linux / Mac OS dual boot system and I want a common directory with symlinks (so NTFS is not an option, as far as I know).

If bugs like this here and #14021 remain open for a longer period of time hfsplus in Linux should probably be marked "unmaintained" or "experimental". This would be sad, though, with Mac OS gaining market share, and the Mac OS kernel even being free software, which should make it a lot easier to support hfsplus (compared to e.g. ntfs).

[1] http://marc.info/?l=linux-mm-commits&m=120778317226957&w=2