Consider the following code (which I'll be submitting as a test case shortly):

class B {
  Object _x;
  void f([num x = 10]) {
    _x = x;
  }
  void g({num x = 20}) {
    _x = x;
  }
  void check(Object expectedValue) {
    if (_x != expectedValue) {
      throw 'Expected _x == $expectedValue; got $_x';
    }
  }
}
abstract class I<T> {
  void f([T x]);
  void g({T x});
}
class C extends B implements I<num> {}
main() {
  C c = new C();
  c.f();
  c.check(10);
  c.g();
  c.check(20);
}

This test fails with the current front end, because when the front end generates forwarding stubs for the class C, it doesn't preserve the default values from B::f and B::g. The front end is adding these methods to the kernel representation of class C:

forwarding-stub method f([generic-covariant-impl core::num x]) → void
  return super.{self::B::f}(x);
forwarding-stub method g({generic-covariant-impl core::num x}) → void
  return super.{self::B::g}(x: x);

(Note the absence of default values for the x parameters). We could fix the bug by copying over the default values from class B, but that would lead to problems with modular compilation, since we don't want to have to preserve default parameter values in summaries. It would be much nicer if we could fix this bug my having a special representation of forwarding stubs in kernel, and let the back end take care of doing the right thing with default parameter values.

@kmillikin I understand you're thinking of making a similar change to how redirecting constructors are represented, for similar reasons. What do you think?