You're right on all technical points : PHPUnit missing from dev dependencies is an oversight I'll fix, and the Unicode limitations are real and should be clearly documented. The NFD/NFKD case is a good catch.
On the use case: fair point. My motivation came from testing MySQL and SQLite full-text search on a shared OVH hosting : the performance with filters was consistently disappointing. That's the itch this scratches. I understand it doesn't match your experience, and that's perfectly legitimate.
https://docs.phpunit.de/en/12.5/installation.html#phar-or-co...
I find this project very impressive and have bookmarked it for potential use in future projects. Thank you for making this.
+1. This eliminates a whole class of bugs in which you declared phpunit as a dev dependency but end up using a class that it brought in without declaring as a regular dependency. Without an external linter, you can’t really catch that until your production code doesn’t bring the class in and throws a fatal error.
2. If you use phpunit class in prod code, you deserve to get a fatal error
2. That doesn’t apply to PHPUnit specifically, but if you, for example, import PHP-cs-fixer as dev dependency, it will bring symfony/console, and if you rely on that on your own code without importing it on composer.json as a regular dependency, the class will be missing when you composer install for production.