It’s more than “just an idea”. It’s how Erlang works. And the Elixir core team is aware of that, but decided on a rebindable approach instead. Elixir is not going to change this feature. If it deeply matters to you, then I recommend you explore Erlang more deeply.

Let’s try to unpick this argument.

First, let’s see a javascript example of mutability:

a = {}

// b holds a reference to the same data as a
b = a

// mutability: we're changing the data
a.x = 1

// data pointed to by b is implicitly changed
console.log(b) // {x: 1}

Now let’s see a javascript example of rebinding:

a = {}
b = a

// rebinding: a points to different data
a = {x: 1}

// rebinding a didn't change anything in b, hence it's not mutability
console.log(b) // {}

The former (mutability) is problematic because it’s much harder to reason about the code. For example if we invoke foo(a), we have no way of knowing if this will change something in a. We need to read the code of foo and all the code it invokes (recursively!) to reliably answer that. This is extremely tedious, prone to errors, and whatever assumptions we have about the code today can implicitly change tomorrow without us knowing it, for example if a team member changes some indirect dependency of foo.

The latter (variable rebinding) doesn’t suffer from such problems, because rebinding doesn’t change the data.

José wrote about rebinding in Elixir and Erlang in detail here:

Of course we can leave the variables rebindable inside the iex, but in the code it should be non-rebindable.

That’s exactly why it should stay the way it is. It’s really fantastic that what works in the repl works in code. If you really want this feature, you can turn it on in credo and activate it so you can’t pull request code that disobeys this rule (I do this). If you need an escape hatch, I’ve even committed an exception to credo where it disallows rebinding unless the variable ends in !