3 small changes

The library doesn't initially compile in VS2010 (which I'd rather stick to; I don't have VS2012 professional installed at work) because the C# version is set to "5" (in all configurations). If I set the C# version to "default" then it can build. So I did a find and replace in Core.csproj, changing

<LangVersion>5</LangVersion>

to

<LangVersion>default</LangVersion>

I noticed something weird... the target framework for ALL configurations appears to be .NET 2.0. It took me awhile to figure out what was going on. I enteré that you are using a couple of tricks.

1. inside Core.csproj there is a separate <TargetFrameworkVersion> for each configuration. 
2.   <ItemGroup Condition="'$(TargetFrameworkVersion)'!='v2.0' And '$(TargetFrameworkVersion)'!='v3.0'">
    <Reference Include="System.Core" />
  </ItemGroup>

So I explained this in an existing StackOverflow question:

http://stackoverflow.com/questions/5006397/targetting-multiple-net-framework-versions-by-using-different-project-configura/23705790#23705790

I think you should mention these tricks in your readme, too.

I hit a problem in NotifyCollectionChangedAction.net35.cs and NotifyCollectionChangedEventHandler.net35.cs:

#if NET20 || NET30 || NET35

this should be

#if NET20

But it does not compile at first, because NotifyCollectionChangedAction is defined in WindowsBase.dll (this is an unusual case because it is in WindowsBase.dll in .NET 3.5, but System.dll in .NET 4). First VS would not allow me to add a reference to WindowsBase.dll because it thinks the target framework is .NET 2.0 which does not have WindowsBase.dll. I solved that by changing the "main" <TargetFrameworkVersion> to v3.5. But of course, after adding the reference, the NET20 versions will not build. So I used your trick:

  <ItemGroup Condition="'$(TargetFrameworkVersion)'!='v2.0'">
    <Reference Include="WindowsBase" />
  </ItemGroup>

I needed Theraot.Core to have a "strong name" because any DLL or EXE that has a strong name must only reference assemblies that have a strong name. This implies that all open-source libraries should have strong names, to avoid inconveniencing someone that is has this requirement (example: at work, they told me to sign a DLL that I wrote because it was used by some other product in the company that uses a strong name. But this meant that I had to sign all dependencies too. Soon, I will add my own open-source library as a dependency. So my open-source library also must be signed. But I am adding Theraot.Core as a dependency of my open-source library... so Theraot.Core must also be signed!)

I guess signing is supposed to provide some kind of security. Since signing provides no security if the key is public, I call the key file "OpenSourceKey.snk" to emphasize that it is public.