{name_b param_v="wh"}{name_a param_x="abc" param_a="fsd" param_y="def"
+}
{name_z param_sd="zka" param_s="df"}{name_a param_y="wtf" param_z="kro
+" param_ch="www"}
[download]

s/
(?:\{name_a | \G)
[^{}]+?
\K
\w++(?<!param_[xy])
="[^"]+"
//xg;
[download]

I appreciate receiving the latest piece of your specification puzzle. I may not have a chance to do anything with it the rest of this weekend,
but thanks anyway.

The implied specification of Re^4: RegExp: pos management in global substitution can be met by changing the regex sub-expression (actually, it happens to be the whole regex)
    (?: \G (?<! ^) | ^ \{ name_a) $param_xy*+ \K $param_any
to
    (?: \G (?<! \A) | \{ name_a) $param_xy*+ \K $param_any
in the function  xform() of Re: RegExp: pos management in global substitution (see Update 2).

OK, so what's the next specification increment? Totally arbitrary embedded whitespace, including newlines? Bring it on!

BTW: The discussion of the "\G assertion" in the Regexp Quote Like Operators section of perlop includes the disquieting warning 'Note also that, currently, "\G" is only properly supported when anchored at the very beginning of the pattern.' (emphasis added). I don't understand all the implications of this restriction, but I strive diligently, perhaps slavishly and superstitiously, to heed it, even making sure that in a regex expression like
    \G (?<! \A)
(end of last match except when at absolute start of string) the  \G assertion appears at the very start of the regex. I mention this because I noticed the expression
    (?:\{name_a | \G)
in your code and I don't know its possible effect(s). You have been warned!