We don't support this, and don't currently have any plans to build it.

When I've seen interfaces like this before, they've been interesting but not useful. My guess is that this is the sort of thing which looks cool but wouldn't really drive any action. Before building it, I'd want to see a prototype which proved the data is useful.

You could motivate this by taking a block of recent changesets (say, 100-200), either from Phabricator of from your own project, manually categorizing them (if it takes 5 seconds per changeset and you do 200, this will take about 15 minutes), and then converting that into, say, a list of files most frequently touched by bugfixes.

I suspect this list will be complete noise and not offer any useful insights. If I'm wrong, that would help convince me that this idea is worth exploring.

(You could also point to another tool which does something similar, and explain exactly how it helped: e.g., what decisions did you make differently based on the data?)

In codebases I've worked on, I also feel like I have a good sense of where the bad code is. Finding it is very easy; fixing it is very hard. Even if this worked as desired (pinpointing "bad" code), I'm not sure how helpful it would be in getting the code improved.

Generally, I think there's a huge range of data utility, from "looks pretty but is useless" to "consistently drives decisions". An example of the latter is profiler data: almost all performance work is made possible by having a profiler. But I think a lot of data is more like the former, and you get a cool looking graph out of it but it doesn't actually drive any decisions. If having data won't change outcomes, I think there are better places to focus our efforts.