It's a war of escalation with advertisers. Google is the arms dealer to both sides. They won't give you what you would need to win.
Of course, this all relies on browser vendor (Google) wanting to add this API. Doing this imperatively with "live code" allows for innovations in userland before browser makers add built in support for it.
Had they not taken away onBeforeRequest with manifest V3, plugins could implement it themselves. Which is the thing you're suggesting...before the request goes.
>The change allows early availability of ip address so that `ipaddress=` option can be matched at onBeforeRequest time.
It is using some other functionality, on Firefox only, to get that early availability. But I'm saying Chrome is a non-starter since onBeforeRequest is hobbled there. So the "early availability of ip address" doesn't help. You need both.
Technically manifest v3 has nothing to do with APIs that the browser makes available to extensions. On firefox manifest v3 is supported with blocking web request[1], which is the filtering api prior to "manifest v3". Therefore the statement that it certain functionality "by definition" is false.
[1] https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
Here's the design document. The hobbling is noted there as part of the spec. "API Changes WebRequest: Restrict the blocking capabilities of the webRequest API."
https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...
That firefox chose to skip that portion of the design and still call it 'v3' doesn't change history. A true-to-spec implementation kills live heuristics.