The point I am trying to make is that this fundamental feature of message queues (limit their length to prevent the memory exploding) should be provided by Erlang and not reimplemented over and over again by developers.This is really a basic feature in any message queue

Why is this a fundamental feature of message queues any more than of other things?

(you can make a data structure which makes memory explode, for instance lists:seq(1, 123456789123456), you can make a program which makes memory explode, for instance by growing the stack enough. Why is a message queue special?)

Because what to do when the queue is full is absolutely application specific.

What happens if the message you can't add is a specific system message that allows the suspension of OTP processes for a code upgrade? Do you end up livelocked? How do you propagate back that you couldn't insert your element in the queue? Do you make message passing an operation that can fail? How would that work over the network when the message telling you something failed is lost over a netsplit? Is it a different kind of failure?

This has very deep design repercussions on the language. It's not impossible, but it wouldn't let Erlang be the same.