"Coalton doesn't actually work" is extremely disingenuous and easily misinterpreted to mean something that is not true. Coalton does work, and has been deployed for use in production on non-trivial, commercial problems. [1,2]
Mutation is an issue with any Hindley-Milner system, because mutation is inherently impure and non-functional, violating principles that the Hindley-Milner algorithm relies on. The Coalton developers have to decide what they want to do about it. Haskell chose pervasive functional purity and monads (but still gives you many type-unsafe escape hatches). OCaml chose weak polymorphism. [3]
Being a sensitive design choice, Coalton has not committed to a strategy for dealing with this, so as it stands, it is possible to use a combination of impure features to produce a type error. However, this does not block productive development. One can:
- Avoid mutation altogether and rely on an otherwise sound type system. Use purely functional data structures built in to the language, or write your own.
- Use mutation in monomorphic scenarios where there will not be any issue.
- Mutate outside of Coalton (i.e., in Common Lisp).
- Be very careful, know that "Here Be Dragons", and carefully use mutation in a polymorphic context, understanding that one runs the risk of a type error.
Until Coalton reaches "1.0" and a language design choice is made around mutation and the type system, one of these strategies must be used. And they have been used, successfully, because idiomatic Coalton code isn't typically mutating polymorphic vectors left-and-right anyway.
With all that said, I do agree with examining a language or tool for caveats, known bugs, and limitations. I don't know how you'd make engineering trade-offs otherwise.
[1] "Using Coalton to Implement a Quantum Compiler" https://coalton-lang.github.io/20220906-quantum-compiler/
[2] "A Language-Oriented Approach to Exchange-Only Silicon Dot Qubit Software" https://youtu.be/F8TezGqCvE8
[3] https://v2.ocaml.org/manual/polymorphism.html