‘TypeAbstractions` arrived 9.8, and is part of reorg’ing for DH. I suggest going through proposal #448, section 3 ‘Extension shuffling’, including avoiding tyvars from the signature scoping over the equations — which I think is the most egregious behaviour.
Of course there’ll be a long tail of code using ScopedTypeVariables, so a language-standard style document must describe it. IMO that should also explain its pitfalls.
Edit: ninja’d by jaror.
I don’t really bother changing existing code to allow ScopedTypeVariables, but I enjoy using it a lot. Makes it much easier to give ad-hoc bindings to local variables during iteration among other things.
I don’t think there is a clear agreement about it between GHC devs 
i think theres 2 axes
specify new language features that can be implemented faithfully without over specifying the exact implementation strategy. for what point does a standard have if you cant have multiple distinct impls that agree on the same codes?
it should change stuff to remove crud. like idk, make map an alias for fmap.
Godspeed to @DavidB, but I think a more realistic approach would be an incremental step to at least update the parts of the report that talk about extension-less Haskell. That is, align the report with GHC’s behaviour with {-# LANGUAGE Haskell2010 #-} and no extensions.
The standard library description would be most affected, but there are other parts of the report like lexical syntax that would require small updates.
Haha, it’s as if you could read my mind 
The big announcement is coming very soon. Hopefully later today.
Thanks, this is great news!
The only unexpected thing I see is the refusal to allocate a new year/version number to the revised report, but I suppose there’s plenty of time to discuss that choice.
[EDIT] To be clear I’m not advocating to extend the scope of the revisions, I think the next official version of the report should stay away from GHC extensions as I said above. I’m just against making the Haskell 2010 report name ambiguous. Call it Haskell 2026 or Haskell 2010.1, whatever, just pick a new identifier.
I think allocating a completely new year number would be less intuitive. The scope of the project is to document what GHC does when you have the Haskell2010 edition enabled. It would be very confusing if the GHC user guide said something along the lines of “GHC supports Haskell2026 by selecting the Haskell2010 language edition, which, despite its name, does not correspond to the Haskell 2010 language standard”. What I want the GHC user guide to say is something like “If you select the Haskell2010 language edition you get the version specified in the revised Haskell 2010 language report”.
I think we could call the new report Haskell 2026 and introduce a new GHC edition called Haskell2026 which is only nominally different from Haskell2010. Perhaps then we could even “fix” the Haskell2010 edition in GHC, but that probably breaks too much existing code.
But then users with existing GHC versions won’t be able to use Haskell2026 directly, and we’ll have years of having to tell people “the new language edition is Haskell2026, but when using GHC it’s basically the same as Haskell2010, and you have to call it Haskell2010 if you want your code to compile with GHC < 10.X”.
On balance I agree with @DavidB that it is better to keep the year number unchanged, and represent the new document as an editorial revision of Haskell2010 rather than a new language edition. Whether it is Revised Haskell2010 or Haskell2010.1 or even Haskell2010’ is up for bikeshedding though. 