The benefit of extending the filter as described becomes especially obvious if you look at the second filter hit (as well as the resulting script) on latter example page, after adding below entry (found via Ghostery) to AdHosts-J:

that seems to depend upon your OS, or more specifically, your text editor...

i cut-and-paste the above via Notepad and can not save the file because the pasting pastes a "square character" in place of that 8203 and i get a "This file contains characters in Unicode format which will be LOST if you save this file as an ANSI encoded text file" upon attempted save...

I haven't seen this script concatenation with separate query params thus far, only with a comma, once or twice with a semicolon, always within the same query param.

If this method is also used for adscript/required-script mixtures, it would be interesting how it's embedded in the page ("&" or "&amp;", etc.). It's important that chained ad paths are intercepted in the page code (vs. headers), because otherwise other anti-adscript filters could be triggered by a chained ad path, which would also remove required components.

Hi Sidki i have an more general idea, i'm thinking we could create a filter wich could log the name of the functions inside a script coming from an ad source. Later we process that log file and create a list of blocking functions.

In that way it wouldn't matter how the script is served to us, also scripts programmed to broke pages if they are not loaded could be fixed by us instead of blocking the full script file.

Well, as far as sidki-configs are concerned, the approach is generally multi-layered where possible.
Regarding concatenated scripts:
1 - First try to cut ad/tracking paths.
2 - Then see if the individual modules have introductory comments which match a list of known ad/tracking comments.
3 - Then see if the contained function (or argument) names match an AdKeys-J entry.
4 - Then see if the function body contains ad strings.

I don't see a way around point 1. The original reason why i wrote this filter was to prevent subsequent "block scripts by URL" filters from matching and blocking the whole enchilada, required modules included. Besides, i like that filter.

I assume that you have something like point 3 in mind. That's fine, but, personally, i doubt that it's sufficient.
Which reminds me... there's an updated version of this filter, too: