Generics: Great! Wonderful! This is something that Delphi has needed for a long time now.

Unicode: Same.

Anonymous methods: Umm... I don't get it. I've seen the explanation various times in various ways, and I still don't get it. What's so special about them?

Oh well. 2 out of 3 ain't bad.

What I'd really like to see, though, are improved properties. Properties are set up to look like variables to the programmer, but they don't look quite like variables to the compiler, which creates some really awkward situations. My two pet peeves are read/write properties and array properties.

Read/write properties: It's not at all uncommon to declare a property that looks something like this:
[pascal]property number: integer read FNumber write FNumber[/pascal]
Basically, this is an OO-stylistically-correct way to expose a properly-encapsulated private variable, and the net result is the same as if you'd simply declared it as a public variable. Sometimes you don't need any more encapsulation than that, and gettor/settor methods would just get in the way. (This was one of the things I hated about C++.)
Problem is, the net result is only the same as if you'd simply declared it as a public variable until you try to pass your not-quite-public-variable to a var parameter. Then the compiler chokes on it. "Left side cannot be assigned to." Is there any good reason why not? It's a read/write property!

There are two possible fixes which immediately come to mind, and I'd like to see both of them implemented. First, allow the following as valid syntax:
[pascal]property number: integer read write FNumber[/pascal]
This would be the simple way, and do exactly what it looks like. Passing this property to a var parameter would simply pass the variable it points to.

Second, if the read and write parameters are separate, have the compiler automagically do what we all end up having to do manually in this case: allocate a temporary variable of the appropriate type, retrieve the property's value from read, pass the temporary variable to the function, then after it returns, send the temporary copy to the write parameter and deallocate the temporary copy. It really shouldn't be that difficult, now should it? Which brings me to the other thing that's more difficult than it should be:

Array properties. The way array properties are currently implemented makes perfect sense, as long as you accept the rather absurd premise that your objects will never contain any data members that are actual arrays! Yes, there have been times when I've used array properties to "fake it" and make something that looks like an array where a real array didn't exist, but they're very few and far between. For all the rest of the array properties that refer to real arrays, we're stuck with the primitive C++ style practice of writing gettor and settor methods even if all we need is direct access. And if you declare an array type, and simply declare your array property as that array type, you still can't do a lot of useful things with it, such as change the length of a dynamic array, (at least not without some horribly convoluted code!) because of the var parameter issue!
Honestly, would it really hurt that much to allow the following as valid syntax?
[pascal]property myArray: array of TMyObject read FMyArray write FMyArray[/pascal]

Also, array handling is a bit awkward in general. For example, if there's an easier way than the following to append a new value to the end of a dynamic array, I'm not aware of it:
[pascal]setLength(myArray, length(myArray) + 1);
myArray[high(myArray)] := value;[/pascal]
It would be a bit simpler if we could do it like this:
[pascal]incLength(myArray);
myArray[high] := value;[/pascal]
Although, to be fair, generics will make it a trivial task to write a simple "AppendArray" function that can be written once and forgotten about, so that's not as big a deal now as it used to be.

Anyhoo, that's my rant for now. What do the rest of you think?

Mason