Okay, so my read on how this issue arose is:
1. When the XBlock conversion was done for the DiscussionsXBlock, its CSS and JS assets would no longer be part of the big XModule bundles.
3. However, get_css_dependencies() and get_js_dependencies() only does naive checking of the pipeline and doesn't have the more painful logic that static_content.html and pipeline_mako/_init_.py have in order to make it work with the minified bundled asset.
I don't want to make the get_xxx_dependenices() functions smart enough to spit back the minified versions. Eventually, we'll want the XBlock runtime to understand bundling, especially for the case where multiple XBlocks want to bundle the exact same library. But that should be built on newer infrastructure that makes use of Webpack, and should not be tied to the the Django-based asset pipeline that we're actively trying to deprecate.
Instead, I'm going to make it so that the get_xxx_dependencies() methods always return the full list of assets, which will then be individually added to the fragment. This isn't ideal, but it gives us a simple, consistent interface for XBlocks and static assets that does the right thing with respect to caching and the CDN.