Let me second the idea of a Render class—it's something I've wanted repeatedly. There is a clear tension between Show's requirements and human-readable outputs: strings get less
readable, we can't summarize/truncate large values, it can't handle
functions...
At the same time, Show is special because it is ubiquitous. We can derive Show automatically, and it's one of the few classes we can expect almost every data type to implement. Project-specific formatting classes cannot fulfill the same role as Show; they require a non-trivial setup cost (which especially compromises the beginner experience!) and they cannot be used by tools and libraries that are not project-specific. What can a library author do to make their types more readable and usable to their users? Today the best lever is the Show instance, which is why I've seen substantially more "unlawful" Show instances in the wild compared to any other base typeclass.
Other languages like Python and Rust have a similar split. I've been doing a fair amount of data sciencey Python lately, and I can tell you that the experience at the normal interpreter (not even talking about Jupyter) is definitely better than in Haskell because things like dataframes are rendered in a human-readable way, formatted as a table and truncated.
Having a human-readable class is a non-trivial proposal on its own, and normally I wouldn't want to link it to a different change. In this case, however, there is a clear overlap: a new Render class lets us have two different to-string behaviors in parallel, which solves the problem in a similar way to the other alternatives proposed like a language extension or changing GHCi.