So I need to send my binary variable to the server.
/bset works exact as expected, with or without the -a switch.
The issue is that -u0 doesn't work as expected, it actually utf8decodes the data to be sent to the server meaning that there's no way to reliably send a byte for byte &binvar to the server.

If we have a &binvar containing 194 169 and send it to the server
-u0: 169 is sent
-u1: 194 169 is sent

If we have a &binvar containing just 169 and send it to the server
-u0: 169 is sent
-u1: 194 169 is sent

I'd expect having 194 169 in the &binvar and using -u0 to send 194 169 and it not be mangled at all. The rest I'd expect to happen as they currently do.

Right. The /parseline -u switch is actually doing the right thing here. The -u switch is not for how the binary variable is handled, it is for enabling/disabling UTF-8 parsing in the core server send/receive routines.

Binary variables, on the other hand, are automatically UTF-8 encoded/decoded in some contexts. They were implemented in this way for historical reasons, ie. to maintain backward compatibility with pre-Unicode versions of mIRC.

That said, some years ago I added an undocumented -a switch to /parseline which looks like it should do what you want, ie. treats the characters in the binary variable as non-UTF-8.

* Parseline out: PRIVMSG #Test :©
That seems fine, but then it actually sends é (utf8encoded the raw bytes) - But combined with the -u0 switch it seems to works as expected: ©

I haven't tested it with invalid an invalid UTF8 sequence, but I think it will likely work.

Good to hear. That's right, you would need to use -u0, since -u affects how lines are UTF-8 encoded/decoded in the core server send/receive routines. The -a switch only affects how the &binvar is parsed in the /parseline command.