|Problems? Is your data what you think it is?|
It's a real shame you didn't take the time to express your doubts regarding the Perl6 proposals so far in a more coherent fashion.
You are not the first person I have heard who has their doubts, and some of them are people with considerable knowledge and experience of Perl-to-date and many of the other languages upon which it draws. Had your start been more coherent, it might have brought out some of the concerns which others have alluded to but not fully expressed, at least not on this site that I have seen.
If you know anything about the Perl language history, you would realise that it already draws upon many other languages for its syntax. From Dec Basic Plus from way back when, to C, Lisp(ish) stuff, to shell scripts and utilities like Awk and SED and many more. What makes perl the language it is today, is the rational approach that has been taken down the years to include those features that are useful, adapting them where possible to fit the general feel of the rest of the language, but not getting bogged down with trying to become the "perfect language"; be totally orthoganal; be complete in some academic way (like Pascal and its Backaus-Naur language definition, smalltalk with it "everythings an object" or Java with its strong typing).
The thing that makes Perl unique among all of these are the basic premises upon which it combines all these seemingly disperate features.
You yourself note that there is room "...to improve perl5...". I think that most people that use perl 5 have there own set of improvements that they would like to make. I do. For some it would be to remove some of the scarier DWIM features, others to increase the orthoganality of the built-in routines. Some would like to the ability to curtail its propensity for trading space for speed. And yet others would like to discard some of it legacy features or improve its built-in support for OO.
From what I've read, most of these points and many more have been raised for consideration in the development of Perl 6, and its now up to Larry Wall and his team to sift through these RFC's and sort out which ones should be taken forward and which ones are best discarded. I seriously doubt that if you put any 10 Perl people in the same room and asked them to put ticks or crosses against the RFC's being considered that you would get any 2 that would agree, never mind a concensus. Given all the different directions that the language could be pulled in, it is going to be a monumental task to sift through them and arrive at a cohesive end product that remains true to the basic premise of Perl. However, given that LW got the language thus far, it seems impertanent to pre-suppose that he will do any less good a job than he has done till now.
You say that "It should be started from scratch...". It has been hasn't it?
Personally speaking, if Perl 6 aquires some features from either or both Python and/or VB, I would not be at all disappointed. Both languages have some features that I think could be useful additions to Perl. Especially if they are adapted to fit with the DWIM nature of existing perl constructs and features.
For me, the thing that sets perl apart from most of the other languages I have used is that with very few exceptions, whatever I try to do with it, once I find the right one, it seems to have a feature, construct or idiom that seems to be specifically designed to deal with my particular problem in a concise and efficient manner. A few notable exceptions are
I'm sure others would argue against some of these, and would add their own. Some of the above are muted for inclusion. Others may just be to far of the scale. Whatever the final decisions are, I'll make my judgement on whether I think they were the right one's once they have been made. You might like to try the same tack.
Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.