I see you've cited an old post of mine on the OCaml mailing list so perhaps I am well positioned to give you an update. ;-)

OCaml has a very powerful type system and several features (polymorphic variants, structurally typed OOP, curried labelled and optional function arguments) that F# lacks. However, these features are not all good. In particular, trying to use polymorphic variants in production code in the manner that Jacques and I described (to solve the expression problem) is a really bad idea. The error messages are so poor (precisely because too much is being inferred) that such code quickly becomes unmaintainable.

Our Smoke vector graphics library is a commercial product written entirely in OCaml that once contained a scene graph implementation based upon polymorphic variants. After years of grappling with the code we eventually replaced the extensible polymorphic variants with an inextensible ordinary variant type. Everyone was happier because the ease of basic use is far more important than that kind of extensibiliy in practice.

We naturally encountered a similar problem with our F# for Visualization library. The F# language provides a feature called active patterns that is not in vanilla OCaml and can be used to solve the same problem. In fact, we have found decorating a OOP representation using active patterns to be preferable to using polymorphic variants.

On the other hand, there are still several places where polymorphic variants still shine. Most notably, when the types involved are not recursive and are used simply to avoid the overhead of defining a sum type. This style can be seen extensively in many of OCaml's graphics-related libraries like LablGL, LablGTK and Smoke. As F# has no equivalent, the only alternative is needless verbosity along the lines of C# code, which is a shame.

So I do hope that F# evolves something to solve this problem but I personally doubt that will be polymorphic variants (because they are so complicated). I suspect a dynamic approach (drawing upon the DLR) will be used instead.

Regards,
Jon Harrop (Flying Frog Consultancy Ltd.).