The change looks good to me, though I've only been looking at the Nickel codebase for a few days and I'm mainly reviewing to get some more exposure to the code. 😁

Do you think it might make sense to add test cases using the examples from the PR description (e.g. in tests/typecheck_fail.rs) to prevent future regressions?

It may be interesting to run the benchmarks on typechecking the nix list lib to see if that affects performance. My occurs check knowledge is rusty but I remember that running it without any form of memoization like this can turn out to be expensive. For the record, although this is not the main subject of the article, efficient and insightful generalization also mentions how to do it in a "lazy" way (and not at each unification).

I remember why this issue has been open for quite some time, now. I think my original plan was to implement path compression first (i.e., when you call get_root, you remember all the unification variable on the way, like if there is a link ?a -> ?b -> ?c -> ?d -> Num and at the end makes the table look like ?a -> Num, ?b -> Num, ?c -> Num, ?d -> Num). Doing so, we can avoid the occurs check at unification, and perform it only when calling to get_root, potentially grouping several traversals into one. This probably requires to remember for each unification variable if the check has been done or not.

In order to implement path compression efficiently, you want TypeWrapper to use Rc, not bare Box, otherwise you will deep-copy your types a lot. But this hasn't happened yet 😕

We can first see what happens on the benchmark: if the numbers are reasonable, this can be a first implementation, and then we can work toward shareable types (Rc) + path compression + occurs check.