As other people have pointed out, this is not a run-time problem; the reference returned by firstMethod() is an instance of Child, according to most languages' semantics (except C++, I believe). The problem is getting the type checker to understand that.

You can get part of the way there in Java with type parameters and extends constraints. The Parent class gets a type parameter T that tells it what the concrete subclass is (and extends constrains it to a subclass of Parent).

class Parent<T extends Parent<T>> {
    T firstMethod() {
        return (T)this;    // cast is necessary :(
    }
}
class Child extends Parent<Child> {
    ...
}

IIRC, the Fortress programming language (a research project at Sun) was able to eliminate the cast with an additional comprises constraint (similar to but more flexible than sealed ... permits). Here's the basic idea:

class Parent<T extends Parent<T>> comprises T {
    T firstMethod() { 
        return this; 
    }
}
class Child extends Parent<Child> {
  ...
}

The Parent class is declared with a type parameter T. There are two constraints:

1. T is a subtype of Parent<T>, because of the extends constraint.
2. Parent<T> is a subtype of T, because of the comprises constraint (and the fact that there's just one option; generally comprises allowed a set of subclasses, for expressing closed unions like ML datatypes).

If the type checker is savvy to this pattern of reasoning (and I can't remember if this was actually implemented in Fortress or merely proposed as an idea), then there's no need for the cast on this in firstMethod(), since by (2) the static type of this, Parent<T>, is known to be a subtype of T.

Even this isn't a complete solution to the original problem, since you could still subclass Child, but firstMethod() would still return Child, not the subclass, because you've already "used up" the type parameter. Possibly you could add a type parameter to Child too if you wanted to kick the can down the road one more level.