Consider me a +1 on this.
There are some unmentioned caveats here:
* We may want/need a slightly longer release schedule.
* `Monoid` is in the Prelude, so this would drag `Semigroup` into the Prelude.
I see two ways to proceed.
The long path:
A straw-man fleshed out version of your proposal that addresses the "sudden change to Prelude" issues some folks have would be:
7.12: Move Data.Semigroup and Data.List.NonEmpty into base. Add a warning about definitions of an operator named (<>) that indicate it will be coming into Prelude in 7.14. We should warn about missing Semigroup instances at any use site of (<>) as they'll break in 7.14.
7.14: Move Semigroup and (<>) into the Prelude in 7.14. Add a warning about missing Semigroup instances for any Monoid instance at all.
7.16: Make Semigroup a superclass of Monoid. Fix the instance Semigroup a => Monoid (Maybe a).
Alternate long path:
Simplify the warnings. Simply warn about any missing Semigroup instance when you define a Monoid instance in 7.12, so the 7.14 changes become simply a migration into Prelude. The downside is that people would now get a warning that force them to import a module that will be redundant in the next release. =/
The short path:
Collapse the first two steps into one step, but this means that nobody gets any warning of new names coming into the Prelude. On the other hand this would get us all the way to done by 7.14. On one hand, the first order consequence the amount of breakage caused by adding Semigroup to Prelude and taking (<>) is almost entirely confined to a handful of pretty printing libraries -- and we already broke those same libraries by taking (<$>). Sadly a second order consequence is that folks import Data.Monoid to get (<>) today, and this would change to demanding a Semigroup constraint, so the fused release would actually cause almost as much breakage as doing it all in one go, among anybody that actually uses the (<>) in Data.Monoid.
I have a preference for one of the long paths, as they at no point break someone without warning.
We could run a poll to see which folks would prefer.
Having default superclass instance machinery would go a long way towards simplifying this story, but I think we've held up all progress on almost everything for the better part of two decades waiting for that situation to resolve without progress.