Years ago, I left a contracted programming job at a startup that paid about $150k annually, to pursue AAA game development, starting in the low $40k.
Whether working the 40 hr/week or in crunch, I was doing something I absolutely loved.
It was both one of the riskiest and best decisions I ever made, and would do it again in a heartbeat.

I'd rather hear about promising emerging techs we'll see in the future than press releases when these are out to the mass public; near future projects (consumer or otherwise) is one of the reasons I read Slashdot daily.

I'm sure in the process some items will be vaporware, but I'd expect the majority of these editor approved stories will make it to consumers.

I think VB5 also supported COM. (Unsure of this.)
MFC was around long before VB6. We were looking to leverage it at the project's inception but found ATL (with WTL) to provide a lite-weight alternative without the bloated class inheritance. Looking back, as good as ATL was, I don't think we would have survived using it without the WROX books and great samples from CodeProject and similar websites.

The problem is both MFC and ATL are essentially just wrappers to a high procedural, highly struct-passing Win32 API. I prefer them to straight Win32 calling, but they are complex and I'd be surprised if there was a way they could be simplified without losing the flexibility offered.

As for VB6, I believe the EXE's it generated were inherently COM enabled. Each program would support IUnknown and IDispatch. If you wanted a C++ program to talk to it, you needed the IDispatch. Inside of the VB6 world, types were great because they were abstracted, but you are right in that once you marshalled a type out of VB6 into the C++ COM space, it was a bit of a pain to have to work with types like a SAFEARRAYS instead of C array (or STL container.)

So for simple communication, it wasn't too bad. For complex interactions (like the ActiveDocuments we implemented) a crippled object model wasn't required but I would agree that it was a complex setup.

VB6 is simple, but there is a surprisingly large amount of power to be tapped from it, if you understand the underlying infrastructure.

Having done some hard core COM programming 10 years ago, for a Computer Based Testing "test driver", our team learned we could spend 2 days to get up a "ActiveDoc" in C++ using ATL, and WTL, or we could do the same thing in VB6 within an hour. Considering how fast it was to implement ActiveDocument and custom COM interfaces, I changed my mind on how weak I perceived VB6 was. (Unfortunately many of the VB trained, customer-based implementors of our interface were not as astute, and even in a VB6 environment didn't understand what they needed to do to create a component that would properly talk to the rest of our system.)

Still, knowing how quickly VB6 would let one get up an interface, I was able to help a room mate of mine create a level editor for our own rolled version of Zelda. It was a little cumbersome to learn how to read individual bytes of the palette based sprite files, but VB6 had all the power there.

All that said, VB6 should die IMHO. After (C# / VB).NET came out, it became a lot easier to make object dynamically talk to each other and perform byte level manipulation.

Spot on; I had a rant / post about this back in 2009 (that I had drafted years earlier)... hoping Apple would take over this market:
http://tronsterhartley.blogspot.com/2009/01/starting-to-clean-out-my-many-drafts-of.html

While it doesn't specifically have to be Apple, it seems that none of the established brands really understand what consumers need in a great car stereo. The Alpine model I mention in the above post included: a remote? Required holding a button for a few seconds to active a feature... in a car Has no way to fast scroll mp3 artists or songs, etc....

The only reason I settled on it was because it could connect to my iPod and play MP3s without a skip between the track. This was after calling up another manufacturer about their models of MP3 playing stereos and being told that gapless playback was "impossible". Thank you business man; you know jack about tech, but it doesn't matter because your company doesn't make a car stereo with a killer feature I need. (Although I could change the color of buttons; which was fun for about 1 day and I haven't touched since.)

I hate Apple's lock-in but vote for their products with my money because they really do care about design beyond what is in a device. It makes all the difference in the world when you have a product that "feels" right. Check out the Nest Thermostat, or Dyson Vacuums to see other companies who also match form and functionality.