The problem I see with this is it becomes very brittle to just silently accept bad class member names.
Before, if I had a method
class Foo a where
bar :: a -> Int
bar _ = 0
and I went to implement something with a typo
instance Foo Int where
baz = id
then I'd get an error, but your proposal it'd just silently be accepted, and lead to to long nights searching for why my instance wasn't doing what I expected long after I'd shipped my product.
This kind of class isn't an academic concern, many real world classes are defined with 2-3 members circularly. Consider Foldable or Traversable.
newtype Baz = Baz a
instance Foldable Baz where
foldmap f (Baz a) = f a
is an innocent typo that would then just mean that foldMap when applied to Baz will silently loop forever with no warning to the programmer. Traversable Baz behaves similarly with the cyclic between sequenceA+fmap and traverse.
I'd argue that I've made typos on member names far more often than I've wanted this feature.
In fact, I've actually tried to live with a very similar lexical scoping design in a toy language of mine I called Kata. In Kata, you could just introduce new members by writing them in a 'public' block, and constrain subclasses by putting in members without definitions, but it was sufficiently brittle that I wound up adding another syntactic construct which could only be used to instantiate definitions not make new names. That resolve the issue and made the language much nicer to play around in.
I'd really rather not switch from a design that is robust and usually does the right thing to one that is more brittle and prone to introducing hard to find bugs. =(
-Edward