Not a good idea. The major problem lies with configuration files. Most applications have several places on your pc where they store "local" information necessary to their correct functioning. The info include hardware available, user preferences, version of complementary packages, and so on. Quite often these info are stored in hidden files and/or directories in your home dir, hence the bad idea.
What is going to happen is that these files might refer to a version of a program installed with OS n.1, but still unavailable on the version installed by OS n.2. There is no guarantee that these configuration files are at all compatible; they might be different, and one version might be overwritten, and the package calling on it might malfunction severely.
If you think that the problem of different package versions running on different OSes is a minor one, you should take a look at this table, which shows the percentages of packages for each distro for which there is a more recent version than the one available in the distro's repos. As you can see, these percentages are dis-heartening.
Unfortunately, the same may apply to code. Do you know for sure the two distros are running the same versions of gcc, make, automake, and so on? You know for (nearly) sure that the linux headers are going to be different (Arch Linux runs kernel 3.11, Debian Wheezy 3.2, everybody else in-between). And so on.
While it is fun to have two or more distros installed, it is much less of a pain to install n-1 of them in a VM. You laways have the possibility to share a folder, when necessary, and you can do something which is more complex with a real disk, i.e., resize the disk as per your needs.