Support the runtime, support the syntax and semantics, change the pattern matcher, write extensive tests, add it to the term_to_binary/binary_to_term protocol, add it to distribution, enable reading of maps in various function calls, enable NIFs to inspect maps, define how to copy maps between processes, change the core compiler.
To a new and experimental language it would be a small change. Try adding a built-in map to C or Java. Lambda expressions took year to add to Java for example.
Now if say Nimrod or Dart acquired built-in sets (I don't know maybe it already does) it wouldn't be too remarkable. They are pretty experimental.
Also there is a difference between having a library and a language built-in. All those languages including Erlang, have libraries that provide associative data structures.
Yes, as built-ins I consider literals (with specific language syntax). Well, otherwise most modern useful languages have at least a library level implementation of some associative data structures. Erlang has them too, dict, gb_tree and a few others.
You'd have to understand more about Erlang semantics to appreciate it. Those who have used Erlang or hacked the Erlang language itself know this to be nontrivial.
It's not the grammar footprint that makes it a large change. It's that a lot of people will change the way they write erlang programs now that maps exist.
Support the runtime, support the syntax and semantics, change the pattern matcher, write extensive tests, add it to the term_to_binary/binary_to_term protocol, add it to distribution, enable reading of maps in various function calls, enable NIFs to inspect maps, define how to copy maps between processes, change the core compiler.
It isn't so simple.