Habituellement, lorsque quelqu'un demande à s'éloigner de quelque chose qui est largement utilisé, bien testé, vérifié sur de nombreuses plates-formes, c'est l'expression extérieure d'un problème sous-jacent appelé "odeur de code" et l'accumulation incontrôlée de "dette technique" ou "code dette". Les archives GNU avaient accumulé une quantité assez importante de dette de code au fil des ans, et lorsqu'une base de code n'est pas correctement entretenue, elle peut atteindre un point de rupture (code hérité, et même code hérité morbide).
Normalement, on mènerait un processus de réingénierie et de refactorisation à intervalles pour garder cela sous contrôle. Donc, la vraie question qui se pose ici est de savoir si une version refactorisée de coreutils a été développée. Cela, bien sûr, inclut la possibilité d'un remplacement pur et simple (comme un cas spécial) - un peu comme Wayland est destiné à être pour X ... beaucoup de ses développeurs viennent directement du camp X.
Ma suggestion est en fait d'aller refactoriser les coreutils. Quelqu'un doit le faire. Et quiconque soulève la question du remplacement des coreutils - votre idée, votre projet.
À cette fin, profitez de toute automatisation que vous pouvez trouver: des moteurs de refactorisation, comme cscout, ou tout ce qui applique des méthodes d'analyse / synthèse plus avancées (par exemple, des réseaux de concepts formels). Mais l'analyse approfondie est encore un domaine relativement nouveau et ouvert de recherche active - et traverse l'intelligence artificielle. (Un ingénieur logiciel robot.)
La plupart des utilitaires devraient déjà avoir des suites de tests en place, de sorte que la validation peut être effectuée avec un changement progressif par étapes + des étapes de test de régression automatisées; qui peut aller assez vite (par exemple 10 mises à jour de révision ou plus / jour). Une complication à ce processus se produit s'il existe des dépendances matérielles ou logicielles de bas niveau n'importe où dans la suite logicielle; car cela implique une validation sur plusieurs plateformes. Je n'en sais pas grand-chose dans les coreutils; il devrait y avoir une sorte de séparation des couches matérielles ou logicielles de bas niveau (par exemple, le nombre d'endroits où coreutils sait quel typedu système de fichiers sur lequel il se trouve doit être minimal ou, mieux, nul.) Les émulateurs et les machines virtuelles, utilisés pour effectuer des tests multiplateformes, ont des limites. Par exemple, Mac OS X est spécifiquement conçu de manière à entraver la possibilité de l'émuler ou de le VM.