> I am not sure what you mean here. This API (available only on macOS) does allow injecting scripts and stylesheets, it does not provide any feasible debugging tools. Granted, you may inject a script that will get some information about what's blocked, but it's far from what's required.

SFSafariExtensionHandler implements SFSafariExtensionHandling protocol, which has this function:

optional func contentBlocker(withIdentifier contentBlockerIdentifier: String, blockedResourcesWith urls: [URL], on page: SFSafariPage)

So, this is used in statistics extension that prevents me ever looking into the console. Helps to shorten the time it takes to add a new rule and see if it works.

> Let's take the simple example - unblocking something. For instance, here is the most obvious example that happens all the time. There may be a regional list that unblocks something blocked by EasyList (or EasyPrivacy) because this "something" breaks an important website in that region. Putting EasyList into one content blocker and the regional list into another breaks the regional list.

I totally agree! This is one of the reasons I don't use those lists as is. Thankfully, many unblock rules can be merged into the corresponding block rules in the form of "unless-domain" specifier.

> We accept that argument despite me being literally sick of hearing it (so there's privacy on iOS, but no privacy on macOS since scripts are allowed to extensions there, okaay).

The statement that there's no privacy on macOS is incorrect. The user can see what privileges different extensions require, and can enable only those they are okay with, like content blockers. Due to their design, content blocker extensions can guarantee privacy, unlike the ones that can run JS code.