See discussion in patch2296 - it looks like darcs may be misusing
encodings and directory 1.3.8 has exposed that.

Short-term workaround is to constrain directory to <1.3.8 -
see patch2363.

That seems to build ok with GHC 9.8, but is presumably not going to play
well with package sets.

I had a stray allow-newer directory:base in my cabal.project.local,
so hadn't noticed that directory-1.3.7 doesn't actually officially
support GHC 9.8. That makes the short-term workaround (even) more
problematic.

I've now spent some more time digging into this. Thanks to Vekhir
whose further comments on IRC helped point me in the right direction.

The basic problem is that if you have a patch with a name that contains
non-ASCII characters, you can't name a patch bundle file after that
patch when the filesystem encoding is set to ASCII.

The current implementation of darcs send makes this situation worse
because even if "-o" is used to override the bundle name, it tries
to calculate a filename named after the patch, and then throws it away
This involves using "doesFileExist" to check if the proposed name 
already
exists.

The behaviour change between directory 1.3.7 and 1.3.8 is that it now
throws when doesFileExist is called on an invalid filename, whereas
before it just returned False. But either way, if we got as far as
trying to write out the bundle with the name, it would fail with
any version of directory/GHC (directory isn't even involved in that).

As it happens, our tests only do "darcs send -o .." in the ASCII
encoding scenario, which is why they passed with directory 1.3.7
and fail with directory 1.3.8.

Overall I think there are two things to fix:
 1. Don't calculate the filename based on patch name unless
    actually needed
 2. If we do get an error calculating it, catch it and give the
    user a helpful error message suggesting they use "-o"

1 is a definite bug, 2 is more being helpful in the face of what
is theoretically a user error.

Note that this would also affect other commands like obliterate that
can write out patch bundles.

The following patch sent by Ganesh Sittampalam <ganesh@earth.li> updated issue issue2716 with
status=resolved;resolvedin=2.18.1

Hash: 96e3c708e90aeff54ed56223b93138f156a3c08e
Author: Ganesh Sittampalam <ganesh@earth.li>
* resolve issue2716: calculate bundle names lazily

  Naming a patch bundle after a patch can fail if the patch
  name contains characters that aren't representable in the
  current filesystem encoding.

  Without this fix, it's not even possible to override the
  bundle name with -o, as the default name is calculated
  regardless.