I always have a hard time explaining why mixed OS in developer groups should use x86 instead of AnyCPU. I found an article that explains it in a real life context. The source for the article is here: http://laputa.sharpdevelop.net/SharpDevelopNowCreatesProjectsAs32bitByDefault.aspx

SharpDevelop now creates projects as 32-bit by default

Starting with SharpDevelop 3.1 RC2, new projects are created with a "Target CPU" setting of "x86". Previously, projects were created as "AnyCPU". This change affects only new projects; existing projects keep their old setting.

Now, what is the difference between these settings? On 32-bit Windows, there isn't any. But on 64-bit Windows, for programs, the "x86" setting means your program will run as a 32-bit process in the "Windows on Windows" emulation layer. AnyCPU programs would run as a native 64-bit process.
For libraries, the new setting will prevent them from being loaded into 64-bit processes.

Now, restricting stuff to 32-bit doesn't sound like it's the way forward. Why did we do this change?

   1. If you never test on 64-bit Windows, the new setting ensures your program will run in compatibility mode. This is better than breaking on your user's 64-bit machines because you unknowingly had 32-bit-only code in your program.
   2. The SharpDevelop debugger does not yet support 64-bit processes.
   3. Microsoft did the same change: Visual Studio 2010 also creates x86 projects by default.

The main problem with the target processor is that you cannot mix libraries with different processor types. If your program is running as 64-bit process, it cannot load 32-bit libraries. If your program is running as 32-bit process, it cannot load 64-bit libraries.
If you have an existing AnyCPU solution and add new projects to it using SharpDevelop 3.1, you should change the target CPU of all new projects back to AnyCPU.

As soon as your program depends on an unmanaged library, you will be forced to pick the corresponding processor type (e.g. SharpDevelop includes 32-bit SQLite and Subversion, so it must run as a 32-bit process). Unless your program is completely managed, AnyCPU is a bad idea because you would have to load a different unmanaged library depending on the process type your program got loaded into.

For purely managed libraries, the situation is different. Here I must recommend to use AnyCPU to allow your library to be loaded into any process type. In fact, in the case of SharpDevelop, only the executable (SharpDevelop.exe) is marked as 32-bit; all other libraries are AnyCPU.