> If I ever dive back into to F#, I think I will treat it as "procedural first with a neat type system" and limit the use of both OO and functional features to where they markedly improve the code.

This may be a good strategy; I would urge you though to try doing top-down design in F# using modules and interface (.fsi) files. E.g., let's design a calculator GUI app in F# using, say, Windows Forms. Sketch out the interface first:

    (* Calculator.fsi *)
    namespace CalculatorApp

    module Calculator =
      type number = Zero | One | Two | ... | Nine
      type op = Plus | Minus | ... | Sqrt

      (*
      Holds the app model. Note that it is mutable; the keypress operations
      return `unit`, i.e. they update the `t` value in place.
      *)
      type t

      val init : t
      val press_number : t -> number -> unit
      val press_op : t -> op -> unit
      val calculate : t -> double

      (*
      Draws the app and hooks up event handlers to the above operations.
      *)
      val render : unit -> System.Windows.Forms.Control

Then in the implementation file (Calculator.fs), fill in the blanks based on the types! Of course you'll need a separate file for the main entry point, but that's good practice anyway.

> It's probably possible to convince me that the limitation on circular references is actually a feature

Have that in Haskell as well. As the community largely views FP as "type-driven development" and Haskell as a "typeful language", it isn't uncommon to have a single module just for listing all the Algebraic Data Types (not their "methods" though, that's more an OOP concept anyway). Having all ADTs at a glance has its own benefits in terms of "high-level overview" etc too of course.

But of course the question was about OOP so you're right calling this a "caveat" in that respect.