Related to this. While you do not provide the granularity of configuration we would like to see. The custom CSS and JavaScript options have allowed us to hide functionality that wasn't suitable for our institution. (For example, you idea of moderation, isn't the UK's idea of moderation). Up until recently, the CSS was usually marked up in a fashion that was easily identifiable. With recent releases, I've started to see unintelligible CSS. For example the class for the the new comment library is
fOyUs_bGBk fOyUs_desw bDzpk_bGBk bDzpk_busO bDzpk_fZWR bDzpk_sGoV
With no ID, there's pretty much no way of knowing if I can target any of these classes to hide that block without potentially causing issues elsewhere (and I'm assuming these classes are dynamic?). Yes, there are other ways to target that block. But it's better if it is easy so all can do it.
Can we please go back to targetable classes and IDs? Otherwise as @michelledennis highlights, we need fine grained configuration facilities to switch off features that are inappropriate for our institution.