Its notion of Monad would need to be picked by do sugar. Today, this would mean using RebindableSyntax in all the client code. Even then the semantics are subtly wrong. With RebindableSyntax you get whatever one is in local lexical scope, not your pre-selected (>>=) and return, so you'd still be able to see through the facade pretty easily.
So, yes, someone could write and maintain a package that doesn't work with anything else and put that package on hackage for backwards compatibility. In fact, we have two packages (haskell98 and haskell2010) that are no longer considered core libraries, which an interested party could step up to turn into something along these lines.
Herbert spent some time working on implementing a proper version of such a vision and filed a couple of issues on GHC for features he'd need to make it viable, but it hasn't happened yet and is a rather monolithic task.
Also due to changes in Num, such a package isn't _really_ haskell98 or haskell2010 anyways, so to do the pedantic version you'd need to supply your own Num and instances.
In the second:
Alternately, a thinner shim could be written, which just uses the existing classes with their semantic changes and tries not to export anything different than before. This design winds up stitched out of compromises, but could be written and maintained by an interested party out on hackage with no tooling required.
While nothing is stopping someone from going off and pursuing these options, from a POSIWID perspective the net result is introducing fragmentation in the name of avoiding a few names, and even if someone invests all of the effort to make it happen, it seems to me about half of the parties interested in such a design would want the other of the two options laid out here, exacerbating the fragmentation issue
-Edward