The Mono runtime Unity uses is, I think, a fork of Mono 2.8. The tailcall op wasn't implemented in Mono until 2.10 (again, I think). The tailcall op is essentially ignored by Unity Mono.
To date, we haven't had a single stack overflow in our 10k LOC app.
I should mention that the style of programming we are using is alot more imperative than the typical F# program. Any potentially large collection is an Array, C# list or Dictionary. F# immutable lists (and maps) are still used in most areas where data sizes are known to be small and allocations are not so important.
The Mono runtime used by Unity has a very inefficient non generational garbage collector (conservative Boehm). A generational GC wasn't introduced until 3.x. Unfortunately this tends to lead to a less functional and more 'allocate once and reuse' style.
The Mono JIT also produces code which is often an order of magnitude slower than MS .net (which itself is slower than coreclr).
Despite these caveats - a significant proportion of code can be written in a purely functional style and good performance can still be achieved.
That's exciting to know. I hope to give F# and Unity a try sometime soon, then!
I remember the XNA C# runtime on the Xbox 360 required similar strategies with memory as well. It's nice to see garbage collectors improve as time goes on.
I haven't had much luck finding concrete evidence though. Is this an issue with Unity and F#?