who hasnt developed a test driven project may easily dismiss the implication of this detail, but having worked with it for some games i can say it's quite deep actually...
you have to write unit tests to see them initially fail (of course, classes and code dont even exist yet), then the (minimal) code that will make them pass (green bar in the test runner - all test methods satisfied), then refactor the code (and the tests, if you change the class hierarchy or method names) to refine the design
this leads to (ideally) have smaller iterations, and working (and pre verified) code at each iteration
but this also implies a NECESSITY to have the whole project developed in TDD, so that each project subunit is covered by tests, so that bugs or regressions introduced with subsequent feature iterations or refactorings, are immediately caught
otherwise there's no point in going TDD at all
this means that, canonical may be "right" or "wrong" by choosing such development strategy, but that doesnt matter - since they have choosen it they can't import foreign, non tdd code any more
so no, they couldnt "just fork" an existing solution ... even if it may work just fine, even if it may be the most popular, even if it's in development for some years and even if its developers are brilliant people, the fact that they havent worked with programmatic description of specification and the fact it comes without unit tests make it a no go
this is important to understand