As an outside observer of Perl 6 development since its conception, I feel that this pattern (Scope creep and massive rewrites / depreciation of current infrastructure whenever one component was in "danger" of becoming useful) has played out over and over again throughout the life of the project.
This went back at least to the original Parrot announcement. Arguably, even the _birth_ of Perl 6 was based on the idea of a massive rewrite, superseding the much more modest Topaz effort (After about two years of development, Topaz had not yet delivered fully working code. The original announcement of Perl 6 promised working code in 18 months).
Parrot and Perl 6 really suffered until Pugs started producing a standalone test suite. If Perl 6 on Parrot had had that in 2000 or 2001, things might have turned out differently.
I normally agree that throwing away working code and starting anew is the wrong approach, but trying to rewrite the Perl 5 internals to support Perl 6 would have taken at least as long as Parrot and Rakudo have taken; it's really that impenetrable in places.
Your phrase "in danger of becoming useful" is quite perceptive though; I wish I'd thought of it.
As an outside observer of Perl 6 development since its conception, I feel that this pattern (Scope creep and massive rewrites / depreciation of current infrastructure whenever one component was in "danger" of becoming useful) has played out over and over again throughout the life of the project.
This went back at least to the original Parrot announcement. Arguably, even the _birth_ of Perl 6 was based on the idea of a massive rewrite, superseding the much more modest Topaz effort (After about two years of development, Topaz had not yet delivered fully working code. The original announcement of Perl 6 promised working code in 18 months).
http://use.perl.org/~masak/journal/40451