Erik, I agree. This issue has been around for almost a year now though. The general case is much harder to implement and get right than such a apecific one; therefore it might be better to start by implementing it for something not too difficult (like highlighting) and see what people think of it. First to see which features are really needed, but also to see whether it's the right approach at all.
Chris, good point. I didn't think about this because in the schema I'm using with the patched Solr instance all fields happen to be stored. I've changed the patch to return only stored fields. Now, this is arguably not the right place for generic give-me-all-stored-fields code and the implementation is inefficient. My knowledge of the Solr code base isn't good enough though to figure out the right place for this code – it needs to talk to both Solr and Lucene code to get all static and dynamic fields. Should this maybe go into the SolrCore code? It could maintain a list of stored fields which is assembled on startup and updated on <commit/> instead of reassembling it for every query.
Note that the latest version of the patch could also easily be tweaked to allow arbitrary wildcard specifications of the fields to highlight (e.g. hl.fl=text_*).