Spin-off from #5289. Windows has a number of characters that can't appear in path components. For portability, we should consider restricting the use of those in package descriptions. I started work on this but it's a yak shave of a yak shave and I realised it was a bigger task than I wanted to take on, with a few squidgy considerations, so here are my notes. I'm not a Windows person, so take all of this with a grain of salt.

• Backslashes could be forbidden in relative paths, since slashes are accepted as a path separator. Except we strictly need them for UNC paths.
• ? is needed for UNC paths.
• For absolute paths, you definitely do want to allow : and possibly UNC paths, too?
• I don't know if we need UNC for relative paths or not.
• I don't know what the other magic characters are forbidden for, or whether we can safely exclude them or if Windows users will complain about having some necessary syntax incidentally disabled.
• What about conditional sections? If you gate some weird pathnames behind os(linux), is that okay?
• The magic CP/M names (COM, NUL, etc) shouldn't be a problem if all file access goes through modern mechanisms, right? I'm not confident that it does, but we might view those call-sites as buggy and needing to be fixed rather than a reason to try to exclude the magical names.
• Case (in)sensitivity.

There are portability worries going in the other direction, too: POSIX paths aren't Unicode, but Windows paths are. Restricting to printable ASCII is one option, but that's horrible. Demanding UTF-8 is attractive, but that might be too controversial still?

Not all of these are necessary to get something useful done, but they're things to think about.