Again from Larry's talk at ALS, here is his list of constraints on the development of Perl 6:
Can Larry understand it?
Do people really need the new feature?
Can we implement it efficiently and robustly?
Does it preclude translation from Perl 5?
Does the utility grow faster than the complexity?
Does the size grow slower than Moore's Law
Must take time to maintain Perl 5
Must take time to design Perl 6 right
Perl will still be Perl
TMTOWTDI ("There's more than one way to do it") -- just because one Perl language construct duplicates the functionality of another is not sufficient reason to avoid it.
Make easy things easy, hard things possible -- if a feature achieves this, it is in keeping with the Perl spirit and is likely to be considered for inclusion.
Perl is not Python, Java, C, BASIC, COBOL, Lisp... and will not become any of these, despite the loud arguments put forward by some proponents of these languages during the RFC process
... but it should be easy for people from those languages to pick up
May also be easier to connect directly to those languages (e.g. Inline.pm, cleaner XS replacement, etc.)
Language changes
Death to global variables! (especially punctuation vars such as $/); these are likely to be converted to some kind of OO interface.
Deprecated features removed. For instance, the use of ' as a synonym for :: will die a peaceful death of old age
Non-critical builtins move out to modules, including formats, shared memory functions, gethostbyname and friends, etc
Easier and safer OO programming
Easier functional programming
No more typeglobs (but none of their functionality lost)
Filehandles become objects
Easier interpolation of complex expressions
print "The answer is $obj->answer()";
Optional typing of scalars (int, float, etc)
my int $answer = 42; my int @array = (1, 2, 3);
Better subroutine parameter specification mechanism
A switch statement, based on Damian Conway's excellent (and very Perlish) suggested implementation
wantarray() becomes a more generic want()
Standard library changes
Greater consistency
More applications development support: web, XML, CORBA, ???
Some stuff moved from the core to the library: date/time, shm*, formats, etc
Internals changes
More modular
Easier to maintain
Much easier to extend
Better garbage collection
We'll know more when we start on detailed design and implementation
Licensing changes
Possible rewrite of the Artistic License