I think the area of contention is pretty small. As I understand it, no-one wants to change the instances you call [standard], for the types
[] Maybe Either tuples () Bool Ordering Char Double Float Handle Integer Int Int8 Int16 Int32 Int64 Word Word8 Word16 Word32 Word64 DataType TyCon TypeRep
This list already includes some [partial] instances - just knowing that these types have 'Data' instances isn't sufficient to use 'Data' operations on them safely (while avoiding runtime errors).
So they might as well go with the Data class. That leaves the [partial] instances that would have to be taken out of syb to make most of the other packages independent of it:
Ratio Complex Ptr StablePtr ForeignPtr
'Ratio' has a complete 'Data' instance, it just isn't consistent; the 'gfoldl' operation assumes a nullary constructor/no visisble constructors (abstract type) while the 'gunfold' operation assumes a binary constructor (concrete type, internal constructor). 'Complex' seems to be missing an instance?
Assuming something sensible is done for the first two, would there really be any need to change these?
That depends on whether the [partial] 'Data' instances can be completed in a sensible way for these types. If they can't, then the way forward would be to split the 'Data' class into those operations supported by all current instances and those only supported by the types in [standard]. That way, one would the presence of instances would at least be indicative of the presence of instance methods, providing more static type safety. But if the 'Data' class and some instances are in 'base', there'd be no changing them (*). Claus (*) of course, it would be nice if ghc's deriving mechanism was based on a derived instance specification in the module providing the class, rather than being hardcoded into the compiler itself; so even with 'Data' out of 'base', that part currently cannot be changed without updating ghc. or if class aliases allowed the generated old-style 'Data' instances to be re-interpreted as 'DataA' and 'DataB' instances.. but none of that is realistic for the current split decision.