Is there a reason the System.Collections.Concurrent namespace (and its members of course) from .NET 4.0 and Mono 2.6 is missing from Unity 4’s Mono implementation?
Because the version of Mono that Unity uses is based, more or less, on .NET 3.5
Well, the Mono 2.6 notes say that it supports parts of 4.0 and in particular concurrent collections (which were offered as a separate library from Microsoft for .NET 3.5, and only became a part of the .NET standard distribution in 4.0, which explains why they could be added to Mono 2.6).
However the notes also says “To use this code you have to manually enable the .NET 4 profile using the --with-profile4=yes switch at configure stage.” Would that explain why the namespace isn’t visible in Unity by default? Is it possible to configure Unity in this way?
Unity doesn’t use the stock version of Mono. They’ve customized it to a certain degree. See http://docs.unity3d.com/Documentation/ScriptReference/MonoCompatibility.html for full documentation on what’s supported and what’s not.
I’m aware of that. I was wondering why it was not included if it was already in the stock version, in the hopes that that would tell me what the chances are of adding it back in, seeking another implementation elsewhere, writing my own, etc.
My guess would be because a lot of the classes under the UnityEngine namespace are not inherently thread safe so they’re mitigating a risk by not allowing you to put them into a Collection that is. For example - enumerating a thread safe collection of Transforms and changing the position from a thread other than the main thread still wouldn’t work because Transform isn’t thread safe. But - I don’t work for Unity so I’m just speculating really. 
That was my assumption too—probably not worth the hassle on their part. Plus, as I mentioned, it’s an optional part of Mono 2.6 so they might have fire-walled those parts off to make their lives easier.