The [`unicode-data`](https://hackage.haskell.org/package/unicode-data) library reimplements most of `Data.Char` in a better way. With better, I mean * [reportedly up to 5× faster](https://github.com/composewell/unicode-data#performance) * only pure Haskell code, no FFI Both seem to be obviously desirable even for base. Faster is better, and pure Haskell makes things like targeting JS or webassembly easier, I assume. Also, it’s more reputable for us :-) As with our current implementation there is a tool that generates some code based on the Unicode standard. It would be great to benefit from Adithya Kumar's work here, and use his implementation in `base`. Unfortunately, it does not seem to be easily possible to for `base` to simply depend on `unicode-data`, as that uses too much stuff that’s in `base` (and not in, say, `ghc-prim`). So the question is: Should we * copy that code (including generator) into base, use it to provide `Data.Char`, and maintain it in parallel with the stand-alone upstream library, or * copy that code (including generator) into base, use it to provide `Data.Char` _and_ the more specialized modules provided by `unicode-standard` that are of interest to users with more precise Unicode needs (e.g. `Unicode.Char.General`), so that that package (if that’s in the interest of its maintainers) can be deprecated and everyone will find it all in `base`. (This [discourse thread](https://discourse.haskell.org/t/ann-unicode-data-0-3-0-apis-to-efficiently-access-the-unicode-character-database/3861?u=nomeata) may be relevant.)