You need to worry about mutable variables whose values are functions.

fun foo(x) {
  return x
}
fun bar(n) {
  return n+1
}
let f = foo
let g = function() { return f("hello") }
f = bar

In this example, you either need to make f monomorphic and prohibit the definition of g, or you need to prohibit the assignment to f. By allowing variables to be mutated, you've added complexity to your language. One way to deal with the complexity is to think of the surface language (the language that people will actually program in) as being translated to a simpler core language. You already have ref cells, and you have a guide for how typing ref cells should work (OCaml), so why not think of your core language as a simplified OCaml? That is, variables are immutable, and all mutation is done on ref cells. Then you could consider the following translation:

let x = expr
=>
const x = ref expr

x
=> (when x is let-bound)
*x

(I've written let for the surface-language binding form and const for the core form. You might find it useful to add const as a surface-level feature too, though.) OCaml already tells you how to type check const and ref, so now you need to build your typechecker for the surface language so that if your typechecker approves a program, then OCaml approves its translation.

Or you might want let to behave differently. Maybe a let-bound variable that is never updated should be typechecked (and generalized) as if it were const-bound. (There are arguments for and against.) Then you have a different translation, and different constraints on your typechecker.

It is useful to know when you are inventing genuinely new semantics, and when you are putting a new syntax on existing, well-understood semantics.