Q:

Why doesn't the scala compiler recognize this as a tuple?

If I create a map: 
val m = Map((4, 3))

And try to add a new key value pair:
val m_prime = m + (1, 5)

I get: 
 error: type mismatch;
 found   : Int(1)
 required: (Int, ?)
       val m_prime = m + (1, 5)

If I do:
val m_prime = m + ((1, 5))

Or: 
val m_prime = m + (1 -> 5)

Then it works. Why doesn't the compiler accept the first example?
I am using 2.10.2

A:

This is indeed very annoying (I run into this frequently). First of all, the + method comes from a general collection trait, taking only one argument—the collection's element type. Map's element type is the pair (A, B). However, Scala interprets the parentheses here as method call parentheses, not a tuple constructor. The explanation is shown in the next section.
To solve this, you can either avoid tuple syntax and use the arrow association key -> value instead, or use double parentheses, or use method updated which is specific to Map. updated does the same as + but takes key and value as separate arguments:
val m_prime = m updated (1, 5)

Still it is unclear why Scala fails here, as in general infix syntax should work and not expect parentheses. It appears that this particular case is broken because of a method overloading: There is a second + method that takes a variable number of tuple arguments.
Demonstration:
trait Foo {
  def +(tup: (Int, Int)): Foo
}

def test1(f: Foo) = f + (1, 2)  // yes, it works!

trait Baz extends Foo {
  def +(tups: (Int, Int)*): Foo // overloaded
}

def test2(b: Baz) = b + (1, 2)  // boom. we broke it.

My interpretation is that with the vararg version added, there is now an ambiguity: Is (a, b) a Tuple2 or a list of two arguments a and b (even if a and b are not of type Tuple2, perhaps the compiler would start looking for an implicit conversion). The only way to resolve the ambiguity is to use either of the three approaches described above.

