Abadí and Cardelli's ς-calculus is a pure FP model that's almost nothing but implementation inheritance, and it's the best starting point for modeling those semantics, at least if what you want to do is design a type system for an OO language.

The basic rewrite rules are almost as simple as the λ-calculus; as I remember the notation, it looks like this:

    e.m → body[e/i] where m = ςi: body occurs in e
    e{m = ςj: c} → {stuff, morestuff, m = ςj: c} where
        e was {stuff, m = anything, morestuff} and
        there was no definition for m in stuff or morestuff

The expr[replacement/variable] notation implies not only replacement but also α-renaming to avoid variable capture just as in the λ-calculus.

You can, for example, define the Boolean values true and false as respectively

    {result=ςd: d.iftrue, iftrue = ςe: 37, iffalse = ςe: 5}
    {result=ςd: d.iffalse, iftrue = ςe: 7, iffalse = ςe: "yer mom"}

and then if you have some unknown Boolean value b you can compute a conditional as follows:

    b { iftrue = ςf: "hooray!", ifffalse = ςg: "aww" }.result

Similarly you can define list node prototypes cons

    { null = ςx: false, car = ςx: 17, cdr = ςy: 72 }

and nil

    { null = ςx: true }

where true and false are the Booleans given earlier. Then you can define, for example, a length function

    { result = ςy: y.argument.null {
        iftrue = ςw: 0,
        iffalse = ςz: 1 + y { argument = ςa: y.argument.cdr }.result
      },
      argument = nil
    }

assuming you have a suitable interpretation of "1 + expression". And, if not, you can rewrite that to something like one.plus { argument = ... }.result, with a Church-numeral-like construction if you're really enthusiastic.

I think the ς-calculus is a lot more ergonomic than the λ-calculus in practice, and I've written things like string-parsing code and vector arithmetic libraries in it, or rather in a programming language I implemented called Bicicleta, which is a thin layer of syntactic sugar on top of the ς-calculus, so you can write things like foo(bar, baz) instead of foo { argument1 = ςx: bar, argument2 = ςy: baz }.result and 3 + 4 instead of 3.'+' { argument = 4 }.result. But it's just syntactic sugar.

I'm still not sure if this was a good idea because I'm really skeptical of whether inheritance at all is a good idea. But if it's a bad idea, it's not because it rules out having a pure FP model or even makes it extremely complicated. It's already common to augment the λ-calculus with things like records, arrays, algebraic data types, even generalized algebraic data types, and Haskell-style typeclasses, any of which add a great deal more complexity than the tiny increment in complexity added by using the ς-calculus as a basis.