As requested, a status update on my progress:

I've been using .Net now for just over a week, and I have to say that I'm
enjoying most of it.
I still take 30mins sometimes to look up some obscure information, and I
haven't attacked the ADO.Net stuff yet (saving that - erk), but I'm whizzing
along happily on most of the other stuff.
One difficulty I experience is knowing whether or not there is a simpler way
of implementing something.
For example, I have some classes that contain collections of other types of
objects, and I first used an ArrayList. I began to implement an interface to
an XML file usng XMLDocument so that each class could read its own subtree,
and spawn child classes when required.
I then discovered (when reading the Professional VB.Net 2nd Edition - an
_excellent_ book) that the XMLSerializer would do this for me.
I changed all my ArrayLists to Dictionary class (better suited to my
requirements)... then discovered that they can't be XMLSerialized :/

This too and fro process is a bit of a pain, but at least once you have
discovered these issues once, they have similarities throughout the
framework.
Reading (and answering) the questions in these technical forums helps a
great deal. Spending 20mins coding a solution to a question is a brilliant
way to force yourself to learn a new area, and I was chuffed (English word)
today to find that I not only managed to get delegates down to a 'T', but
also came up with a nifty way of dynamically triggering events from
dynamically created timers.

However, my overall appraisal of VB.Net and its complexity remains
unaltered. I still think it is a very tricky thing for conventional VB
developers to come to terms with, and I'm now experiencing that first hand
as one of my friends (who has programmed VB and VBA for about 8 years)
struggles to grasp many of the concepts of the strong object usage in .Net.

I am convinced that the only reason I am able to pick it up quickly is
because of my experience in Java and C++. I now frequently find my mindset s
witching into the OO design mode where I consider subclassing existing
objects to solve a problem, and I'm at the point where the decision to
subclass no longer fills me with dread as it did when I first started
("Damnit, where's that example code with all the syntax I need in the
Moron's Guide to VB.Net?")

As a genuine comment (and this is _not_ flame bait), I would suggest that
while strong VB developers with a little OO experience could probably pick
this up and run with it in relatively short time, it is a thought process
modification (or 'paradigm shift' as they sometimes call it) that will
almost certainly defeat any weak developers, so that rules out about 50%-70%
of the VB6 people out there :/
Just read some of the support questions to get an idea of what I mean. It's
not the questions about specific bugs that are worrying (we all miss the
obvious problems sometimes), it's the descriptions of what people are trying
to do that shows how little people actually _think_ about the problem they
have to solve, and hence the solution they are creating.

Cheers,
Jason S (iGadget)

p.s. Thought I ought to be using my real name so that I don't get accused of
'hiding behind a pseudonym'
p.p.s. Do not confuse me with the other 'Jason'; I am the real one