I’ll try to figure out the rationale for each idea, as if I was to explain to someone else and convince them it is both worth pursuing and not in the scope of a forge, reason why it has to be implemented as a separated web service.
You have me convinced on this one. It’s not in the scope of fedeproxy but it becomes increasingly necessary. One outcome of the User Research is that the number of publicly available forges is growing fast (although the majority of them are not open to the general public). There is a need for something like https://instances.social, a search engine, etc. A meta forge of some kind. And, obviously, this service needs to be federated.
Hum 
… but if it is federated, why wouldn’t it be in the scope of what a forge provides? I mean, imagine forges are federated natively. They all have the ability to federate each and every features they provide. Issues, pull requests, etc. It would make sense for them to get a list of all forges in existence from the “aggretated forge” web service, get information and send data.
That’s a brain dump @aschrijver, forgive me 
I’m now convinced that you have a point but I’m confused as to where it should be implemented.