For example:
//echo -a $replace(lol},},<)
turns out to be: lol} <

But:
//echo -a $replace(lol},$chr(125),<)
works: lol<

Tested with 6.14

its not a bug, take a close look at the output. the 2nd } is having the effect of closing the $replace becuase its on its own its been seen as a closer of a command not a argument.

check this out

//echo -a $replace(lolx},x},<)
lol<

becuause x} becomes an arguement. Its just life i guess.

Well I can't see why wouldn't it be a bug, but it certainly is an inconsistency that should be corrected at least. Just because an identifier parses arguments differently compared to a command, it doesn't mean that it should interpret the meta-'}' just because it's alone as a parameter. It's next to two colons, so it should be the literal '}' char..

Well i might fall back on the old failtfull the pharser is getting confused line. LOL

check this out for it getting confused...
//echo $replace(lol},o,}) x
lxl}

now theres something really wrong there!

I even played a little bit with $regsub....didn't work either.
I also found out that { and } will screw your hole output, if you use it in most of the text-identifiers.

You should be using $chr for odd characters. If you are like me and just hate having to find the ascii value all the time, use something like this.

alias ascof { echo 4 -ae $1 = $asc($1) }

That's only needed for chr 44 (','). You can use $eval({,0), $eval(},0) and $eval(|) (that's right, '|' can miss the 2nd parameter, '{' and '}' must be bugged), or their most compact forms: $({,), $(},), $(|).