You're welcome 
I think the width / height concepts are pretty good there, they translate to when an output gets \n-ed or truncated etc.
Thanks for the reply there -- that puts much into context. I'm convienced that changing those semantics is not a good idea. Though, Nate sums the conflicting use cases up very well there – what debugDescription is is more about where it's printed, and not with what intent. So we can't change names and semantics etc, but...
So pprint will have to follow the same semantics, using debugDescription of elements if inside a collection etc. That's good and I understand why we want this (though would love more docs on the protocol why/when it gets invoked).
At the same time, while introducing a pprint could it also serve the "interactively (println/log) debugging" use-cases (3 & 4). It seems to me it might easily address those if it had a way to use a Mirror to obtain all the values to print -- then description and debugDescription both contain things which normal users may want to see, and some pprint(mirroring_pickBetterName: value) would do what I was after all along -- print "all" the values pretty formatted (multiline etc), as I've now realized that using debugDescription for manually doing the pretty multi-line print leads to unexpected outputs (because collections).
Do you think this is something we could consider having as part such API?