For example:

Prelude Darcs.UI.Options.Core Darcs.UI.Options.Flags Darcs.UI.Options.All> oparse patchname id [(PatchName "\381")]
Just "\381"

Prelude Darcs.UI.Options.Core Darcs.UI.Options.Flags Darcs.UI.Options.All> ounparse patchname id (Just "\381")
[PatchName "}"]

We should either try to fix this and add unit tests to check that they are inverses for each other, or document that they aren't inverses.

The intention is that they are inverse. The reason this fails for
patchname is the use of D.Util.BytesString.decodeString. It is defined
there as

-- | Take a @String@ that represents byte values and re-decode it
acording to
-- the current locale.
decodeString :: String -> String
decodeString = decodeLocale . encodeLatin1

This function is also used by the options 'author' and 'from' (but not
by e.g. 'to' or 'cc'), and in D.UI.Flags.getEasyAuthor.
D.Util.BytesString does not define an inverse function.

My problem is: I do not understand why the decodeString function is
needed at all.

I have just verified that base-4.4.0.0 first introduces a locale-aware
System.Environment.getArgs. Unfortunately I could not find out which ghc
version that corresponds to. If the ghc version is older or equally old
as the oldest supported in Darcs, then I guess we can simply remove the
decodeString function and all its uses.

Darcs supports back to GHC 7.4, which uses base 4.5.

Using a standard function is attractive if it works. Otherwise, could we use decodeString 
on the whole command-line at the point we get the arguments?

I'm not sure what is supposed to happen to defaults read from files rather than the 
command-line.

Ok. (I see now that the cabal file, too, lists 4.5 as lower bound.) That
means we *can* assume that the String we get from getArgs uses the
user's current locale when it converts the command line args to a
String. *If* later stages correctly encode the String to utf-8 when
storing it in the patch file, then there is nothing else to do and
decodeString can *and should* be replaced with 'id'.

I like the idea of adding unit tests. I think QC would be well suited.
Now I need to find out how to add QC tests to the test suite...