The decode then encode test in patch1654 fails if we remove the 
restriction that the string to decode should be <=4096 bytes. I 
think this is a bug in knob as that does something in 4096 bytes 
chunks.

I also assume (but haven't double-checked) that this is a regression 
from 2.12.

I experimented briefly with using [bytestring-handle]
(http://hackage.haskell.org/package/bytestring-handle) to replace 
knob but didn't get it working, not sure whether due to lack of 
time/a stupid mistake, or a fundamental problem with the idea.

This looks like a bug in the knob library, or at least an
incompatibility. It hasn't seen any updates since 2012. Looking at the
code doesn't reveal any obvious faults, but it does use a lot of GHC
internals, including GHC.IO.Buffer where I guess the incompatibility
lies hidden.

Particularly, I see this line

	newBuffer _ = IO.newByteBuffer 4096

in knob source code which is a pretty strong hint...

Let's take a step back. The only reason I have introduced knob is to get
at the functionality of GHC's internal fileSystemEncoding. When you look
at GHC.IO.Encoding you see that they actually expose the encoding and
decoding functions, it's just that they work in a stateful manner on
things of type GHC.IO.Buffer.Buffer. I wanted to avoid having to fiddle
with these things but it looks like we have to.

I think I can come up with reasonably compact versions of encode and
decode that work more directly with a given TextEncoding.

I think
http://hackage.haskell.org/package/base-4.10.1.0/docs/GHC-Foreign.html
has everything we need. Converting between CStringLen and ByteString is
explicitly supported.

See patch1658.