I don't think the loss of callbacks/function pointers is entirely correct. The CLR exposes Events and Delegates to support function pointer(s).

A delegate is managed class that allows you to work with type-safe function pointers. This is to support more advanced features such as events and multicasting.

Delegate Sub MyDelegate(ByVal s As String)

Module MyApplication
   
   Sub MySub1(ByVal s As String)
      System.Console.WriteLine("MySub1=" & s)
   End Sub

   Sub Main
      Dim MyFunctionPointer As MyDelegate

      MyFunctionPointer = New MyDelegate(AddressOf MySub1)
      MyFunctionPointer.Invoke("Sample Message 1")   
   End Sub

End Module

I would agree however that there are significant changes imposed by the CLR which may not be to everyones tastes. It begs the question why bother with VB.Net? If the argument to use VB.Net is one of productivity, solely based on your understanding of the current VB grammar then this may not be enough. As a developer you will still have to understand the concepts routed in the CLR, things like value and reference boxing (performance), events and multicasting to name just a few.

Currently C# is the only MS language in the .Net box that fully embraces the CLR. Will there be an emphasis shift from VB?