Hmm I spoke too soon. The filter is loaded client-side using the QueryAbuseFilters API module. This means that we should first allow global filters to be searched via this API module, which is also a broader change (which I think would be fine). The real problem is that this module queries the database directly (as opposed to using FilterLookup), so it's not immediate to make it work with global filters. In fact, I don't even know whether query modules are supposed to query foreign databases. It might be doable with some hacks, but I'd rather not hack something if it's not supposed to be done.

Second issue is checking user permissions. Since the filter is stored on another DB, we'd have to check permissions on that DB. This is also not implemented in AbuseFilter (as a matter of fact, if you go to Special:AbuseFilter on a non-central wiki and select "global filters only", none of the filters can be viewed). Once again, this is a direct consequence of a core limitation: PermissionManager is only meant to use the local database, and it has no way to inject a foreign one. UserGroupManager (which is used by PermissionManager to retrieve a list of user groups) does accept a dbDomain parameter for foreign databases, but PermissionManager doesn't use that.

All in all, I'm afraid this task isn't trivial at all, but rather nearly impossible until these core limitations are overcome.