+8  A: 

Totally unofficial guess:

If a constructor allowed an IEnumerable<KeyValuePair<TKey, TValue>> you would have been able to supply multiple items with the same key and what would be the expected behavior of that?

E.g. you could have done something like this:

var kvps = new[]
{
    new KeyValuePair<int, string>(1, "Foo"),
    new KeyValuePair<int, string>(1, "Bar"),
    new KeyValuePair<int, string>(1, "Baz")        
}
var dic = new Dictionary<int, string>(kvps);

You could argue that this should simply throw an exception to be consistent with the behavior of the Add method, but I would guess that the design team thought it would be a greater source of confusion than actually useful...

Mark Seemann
As more in the same vein, we can see that `Dictionary` also 'lacks' an `AddRange` - for a similar reason perhaps?
AakashM
Whilst this might not be the official reason, it's good enough to justify the absence of the `IEnumerable<KeyValuePair<TKey, TValue>>` constructor.
Programming Hero
+1 That's a good point - and probably quite close to the truth. However if that was the design decision then it's a flawed one: I could pass in a Dictionary<TKey,TValue> instance that uses a less restrictive IComparer (e.g. the default StringComparer versus the case-insensitive one) than the new one which could still generate an exception. One IDictionary does not necessarily another IDictionary make.
Andras Zoltan
@Andras Zoltan: That's a very good point :)
Mark Seemann
They probably should have left out the constructor overload that takes an IDictionary *and* a comparer. The architect responsible for this has probably been kicked upstairs by now. :->
herzmeister der welten
"They probably should have left out the constructor overload that takes an IDictionary and a comparer" - I disagree. If you want to copy a dictionary that's using a custom comparer, then you need this constructor. Obviously you wouldn't want to copy to a dictionary that's using a *different* comparer, but people who use advanced features like comparers will be expected to know this.
Joe
@Joe - I agree that they should not have left out the constructor; but what about code that doesn't know where that Dictionary, or IDictionary comes from? In any case, the ctor that takes an IDictionary and an IEqualityComparer is next to useless if the intention is to clone a new one that uses the same comparer as the input dictionary. If all you have is the IDictionary instance, then you can't actually obtain it's key comparer. What they should've done is to put the IEqualityComparer in as a property of IDictionary<Tkey, TValue>
Andras Zoltan
@Mark Seeman - I'm marking this as the answer as I believe you've nailed the thinking behind the architecture; which therefore does answer the question. However - I think we can see that it was indeed flawed thinking!
Andras Zoltan
@Andras "What they should've done is to put the IEqualityComparer in as a property of IDictionary<Tkey, TValue>" - again I disagree. I think it's right that the IDictionary interface contains the minimal API needed to use a class as a dictionary.
Joe
@Joe - of course - you're right; I think ultimately this IDictionary ctor should be done away with - because it pupports to provide guarantees to the caller that it cannot guarantee. Therefore it should be demoted to the IEnumerable one, with the IEqualityComparer overload also included. to me, that would make sense. In the meantime, I'll just use a factory method!
Andras Zoltan
A: 
  public static Dictionary<T, U> ToDictionary(
      this IEnumerable<KeyValuePair<T, U>> source)
  {
    return source.ToDictionary(kvp => kvp.Key, kvp => kvp.Value);
  }
David B