This is pretty common when adding immutability to a language that wasn't designed around it. Whether it's JavaScript's `const` or Java's `final`, languages almost always add shallow immutability rather than deep. My sense is that it's quite difficult to add deep immutability in later.
Rust is the main exception I'm aware of, and it had deep immutability from the get-go.
Scala has immutable types in the standard library too, but I don't think they make much sense without the language being statically typed. By which I mean adding immutable types to Python or whatever's stdlib would not be that hard, but it would most likely be confusing since you don't know for sure what you have until you look at it and see.
Rust's deep immutability is different than most in that it allows setting a reference as recursively immutable even if the data type it's pointing to has mutable fields.
Scala gives you immutable data types but unless I'm mistaken there's no way to say "recursively disable mutating functions for all elements in this list"—you just have a list that cannot be mutated. If you stick a Java object in a Scala list, it's liable to mutate, so Scala has shallow immutability.
Yeah that's true, it is different. Neat :). With Scala you would put immutable types in your list if you wanted to, but I get what you mean, it's not the same.
Scala's immutable types are also "shallow". For example you can put mutable objects inside an immutable container and change them when you want. Rust avoids this using lifetimes.
It would be interesting if mutability was actually part of Scala's type system, for example if immutable Seq was defined as
Accidentally mutating globals was a big problem with the language. Const didn't solve it completely: you can still implicitly create globals by forgetting to declare the binding locally. But at least if you have a global you can make it an immutable binding and get warned about mutating it some of the time (ie assignments). As far as I'm concerned that is all it is useful for. For a local binding you don't really get much benefit since it's not deeply immutable, and it isn't an improvement to the ambiguity of local/global scopes, so you're frankly better off not using it as it will trick newcomers.
The same argument doesn't apply to Data's shallow immutability. It will give you errors when mutating at least some of the fields. If your code can catch you mutating a number, then you can notice the bug and be reminded to make deep copies etc. It's an improvement, just like Object.freeze.
This is exactly the same problem that OP was drawing out with Ruby's Data: the references inside the Data object are immutable and cannot be changed to point to other objects, but once you've dereferenced the (immutable) pointers there are no immutability guarantees. Hence, shallow immutability.
The only conceptual difference between this and JS's `const` is that you can't use `const` to declare object properties immutable; for that you need Object.freeze().
Rust is the main exception I'm aware of, and it had deep immutability from the get-go.