So this presents a bit of a conundrum, because if you let it apply to all elements then it applies to QUOTED!s too, and you may have explicitly put that quote on to avoid getting a binding.
If you follow the evaluator's rules for binding then it's kind of removing the agnosticism you would expect SPREAD to have about what you plan to do with the code.
Hence I think... probably it's a bad idea for SPREAD to do this.
One way this particular case could not break is for COLLECT to give back a block which has the same specifier as its input block by default, instead of unbound? :-/
I don't think I like that (though I'm not sure exactly what makes it different from COMPOSE in this respect). I'd probably prefer:
spaced in [] collect [
...
keep spread ["HTTP/1.1" response.status status-codes.(response.status)]
...
]
That might be more palatable than having COLLECT producing blocks with attached environments.
It really is looking like those who build code programmatically need to be actively involved in binding...
...it feels a little sad to see examples like this becoming "more complicated". But as I've said before, the reason that Rebol examples seemed to "just work" at times is because nothing tricky was being tried. Once you do try something beyond the most basic of cases, you'll get bit by the assumptions.
At least if you find yourself repeating any pattern enough times you can generate an abstraction for that pattern. Automatic behaviors probably hurt more than they help.