A test case, with expected, and actual, output would be useful in these cases. But I at least found and fixed the first half of what you've described here.

It was the same bit of code I was pasting there and after comcode-code didn't work out I tried just code (and it tried to run the loop I guess).

https://pastebin.com/9BME6qEE

Using code or comcode-code tags, Composr tries to run the loop (just tested again). A parameter, _loop_var, is referenced in the template, ???, but not passed

Why do you have a raw HTML tag inside comcode-code? It looks like you were hand-typing inside the WYSIWYG source view, or manually adding a link using the WYSIWYG editor.
Neither of those things are meant to be done, because it produces a non-nonsensical situation - comcode-code is not user-editable syntax, it's a means to an end to allow WYSIWYG to work. If normal typing was done inside the WYSIWYG, or pasting, it would show as HTML-entity-encoded.

If it is running the loop though, that is a bug, and I'll look into it.

Umm, not sure, I just assumed code was code and would be accepted as such. I pasted it into a forum topic on a brand new live install just a reference. I didn't know there were rules on what you could put inside code tags.
I couldn't paste the cookie consent code either on Compo.sr forums, without it getting mangled. I used the button on the WYSIWYG screen and then went to source to paste code.

Actually it's not running the loop. It's parsing the $PAGE_LINK symbol on the <a> tag, and that <a> tag is not supposed to exist. Just don't type comcode-code contents manually into the WYSIWYG source view.

The parsing of the code tags when the WYSIWYG editor is involved is necessarily complicated by the way. In Comcode 'code' means that the contents is direct-typed code, but with WYSIWYG that is embedded within an HTML context. This means it has to be converted back to raw code, and then re-processed. If there is actual active HTML in there, not just encoded text characters, then that's paradoxical (makes no sense for a 'code' tag) but will be allowed to flow through but with the same level of HTML security that the posting user has.

There is no <a tag in Cookie Consent and it stripped most code out. Made the comment into a link on preview :)

(Click to enlarge)

For reference, here is why the current processing rules are needed. Take this WYSIWYG-edited code...

https://pastebin.com/s3zqVwXi

should process to the following HTML, basically...

https://pastebin.com/xfCsFB6k

NOT...

https://pastebin.com/zVzxye7F

Because when the WYSIWYG editor is involved HTML tags represent visual layout (e.g. div, br, p, etc) will inevitably get in there just through basic use of the WYSIWYG editor. If we process this as if it is meant to be displayed as the raw HTML it will totally confuse the user.

I suppose we could try and handle different HTML tags differently rather than let them all through, but that would be even more confusing.

Discuss with me on IRC if you like. It's very hard for me to deal with this unless I see exactly what is pasted in, how, on what browser, and the sequence of events that happen after.
This may be partly due to our security filtering as HTML script tags are involved, I'm not sure.

I've fixed a number of bugs around this.

To reiterate, don't paste anything inside comcode-code inside the WYSIWYG source view, it'll never do what you expect and is not supported.

I have tested and you can paste directly into a code tag inside the WYSIWYG editor main view on Chrome. On Firefox there's a bug in that it force-closes the code tag mid-paste. You can workaround that by holding shift when pasting, or by pasting THEN selecting the text and clicking the code tag button.

But none of this will work well until the next patch release, due to the variety of subtle bugs I had to fix.