Tcl Source Code

There is indeed no encoding binary, but the channel may be binary, so why still not consider it like in 8.x as binary encoding?
And a setting this via translation is a bit different to me: it'd also change `eofchar` and `translation`, what is correct for pure binary mode of channel, however if one uses something like:
```
chan configure -encoding binary -eofchar {}
```
the expectation is rather that `translation` remains `{auto crlf}` or `{auto lf}` **depending on platform.**

So why not just "revert" back to the 8.x handling for consistency and just accept pseudo encoding name `binary` for binary mode retaining translation as it is?

Let alone iso8859-1 is never comparable with binary mode, because one prefers strings another bytearrays (and for example strictly seen iso8859-1 has to reject all chars 0x00-0x1F and 0x7F-0x0F), so it is still more confused then (and previous handling of 8.x. remaining binary as value is more consistent).

Why having an artificial encoding name (what is not really an encoding just a mark for bytearray handling) is so bad? Take a look at `unicode` - it is also not existing encoding, but just a mark for unicode handling, nothing else. But the name is pretty usable.

<blockquote>> Many people use "-encoding binary" while they really mean "-translation binary".</blockquote>

This is not an argument in my opinion:

1. RTFM
2. In case of "backwards compatibility vs. theoretical possibility for typo" we shall always prefer the first, because...
3. If one would consider arguments like that, then let us forbid everything what can introduce a confusion (hardly possible in a script-lang, especially in that with EIAS model) and ignore every compat question in the future.

So I'd just switch back to 8.x handling: `binary` is valid value that can be set with `-encoding` parameter similar to `unicode` (which is also unknown encoding, rather a sign we'll work internally with unicode string instead).
But as already said, I'd really use `binary` as return value (instead of iso8859-1)... again, similar to 8.x, to unicode pseudo encoding, and pretty backwards compatible.