Suppose we have:

@PlanningSolution
class A extends B {
   @ProblemFactProperty
   Object extra;
}

@PlanningSolution
class B { ... }

and then we do:

Solver<B> solver = ...; // SolverConfig.xml with B (not A!) set as the solution class
A a = ...;
solver.solve(a); // extra will be ignored!

This is very counter intuitive when users make this mistake.
We can't fix it so it works as they expect it to work, because when reflecting over B, we can't reflect over all subclasses of B (that would require too expensive and too brittle scanning).
But we can fail-fast, as that they'll see their mistake quickly and fix it. Right now, when this happens, I doubt there are any valid use cases for this (and worst case scenario we can allow those by a flag later if anyone actually does it). The only thing I can think of is testing hacks, but they can use separate Testdata objects instead of doing hacks like this.