Languages can incorporate as many features as they like, but where two features conflict, they have to privilege one over the other. Nothing stops a language from having both statically- and dynamically-typed elements, but the library it ships with is going to privilege one over the other, and it's going to drag the rest of the code in the language in that direction. Nothing stops a language from having both immutable and mutable elements, but the language is going to have to privilege one over the other. (If all the library code uses mutable values, then you will have a harder time using immutable values with it; if all the library code requires immutable values then you'll have to copy a lot of stuff if you're using mutable values.) And so on and so on for a large number of features.
In the end you can not help but have a language that is either a "systems" language, a "scripting" language, or something uselessly in-between. You can't help but have an "imperative" language or a "functional" language or something uncomfortably in-between. And in a lot of ways it's more the libraries driving this than the language itself; a language can be a kitchen-sink language but when it comes time to write the function that splits a string on the given character, you're gonna have to choose whether the strings are immutable and how arrays get allocated and how they get passed by that specific function no matter how flexible the underlying language is. Multiply by several hundred for even a simple standard library. (And there will be a standard library; even if you don't bless one by the language designers the community will develop a "standard" loadout and make the decisions for you even if you didn't.)
You can imagine this sort of language as being a good idea because you can hide in the conceptual ambiguities in the vague idea, but when you try to manifest it concretely, you can't help but make a long series of decisions that will create a language that is better at some things than others, or, if you choose sufficiently poorly, not terribly good at anything.
You can always do the "multiple language on the same base system" approach; it's not just Java that works that way with its virtual machine, it's the way the real machine works too. You've got the base machine code and a whole bunch of things that back to that already.
> but the library it ships with is going to privilege one over the other
This really just seems to me a matter of no one having done it right yet...
Following your example (which I like), I can have both mutable and immutable types in my language. Your point is that the library will favor one or the other, but I think you admit both libraries are possible. Why can't I have twice the library?
Yeah, it might be more work to have a library twice as big, (and again, no one seems to have done it yet) but it's not more work than having two languages with two libraries.
All that to say, you're summarizing what's been done, but you haven't proven that something better couldn't be done.
In the end you can not help but have a language that is either a "systems" language, a "scripting" language, or something uselessly in-between. You can't help but have an "imperative" language or a "functional" language or something uncomfortably in-between. And in a lot of ways it's more the libraries driving this than the language itself; a language can be a kitchen-sink language but when it comes time to write the function that splits a string on the given character, you're gonna have to choose whether the strings are immutable and how arrays get allocated and how they get passed by that specific function no matter how flexible the underlying language is. Multiply by several hundred for even a simple standard library. (And there will be a standard library; even if you don't bless one by the language designers the community will develop a "standard" loadout and make the decisions for you even if you didn't.)
You can imagine this sort of language as being a good idea because you can hide in the conceptual ambiguities in the vague idea, but when you try to manifest it concretely, you can't help but make a long series of decisions that will create a language that is better at some things than others, or, if you choose sufficiently poorly, not terribly good at anything.
You can always do the "multiple language on the same base system" approach; it's not just Java that works that way with its virtual machine, it's the way the real machine works too. You've got the base machine code and a whole bunch of things that back to that already.