Vista - mangling com object in outlook/mapi

(Using PSV2 CTP3)
I'm writting a little 'hack' to pull information out of other users shared
outlook calendars. I've actually got it working but really dont like it as I
have had to use some VBscript inside PowerShell as documented in Bruce
Payette's PowerShell in Action. (Listing 12.8 p415)
My problem is that the MAPI COM object returns me an object which I then
need to pass back to the MAPI but it appears to me that PowerShell mangles
the object (in a .NET way) and the MAPI object barfs (is sick) on the managed
object.

I'm interested on the communitys thoughts, a short demo will help:
$objOutlookApplication = New-Object -com Outlook.Application
$objOutlookNameSpace = $objOutlookApplication.GetNameSpace("MAPI")

#Set your username
$user = "Jeremy Pack"

#Create the recipient object
$objRecipient = $objOutlookNameSpace.CreateRecipient("$User")
$objRecipient.Resolve() >$NULL
#Check if the username resolved
If (!$objRecipient.Resolved) {throw "You have a bad user name, try again"}

#Its all going greate so far.
#So now we get a shared calendar folder passing the recipient object we just
#Got back from MAPI
$objCalendar =
$objOutLookNamespace.GetSharedDefaultFolder($objRecipient,"olFolderCalendar")
Cannot convert argument "0", with value: "System.__ComObject", for
"GetSharedDefaultFolder" to type "Microsoft.Office.I
nterop.Outlook.Recipient": "Cannot convert the "System.__ComObject" value of
type "System.__ComObject#{00063045-0000-00
00-c000-000000000046}" to type "Microsoft.Office.Interop.Outlook.Recipient"."
At line:1 char:59
+ $objCalendar = $objOutLookNamespace.GetSharedDefaultFolder <<<<
($objRecipient,"olFolderCalendar")
+ CategoryInfo : NotSpecified: ( [], MethodException
+ FullyQualifiedErrorId : MethodArgumentConversionInvalidCastArgument

So its all gone horribly wrong. PowerShell has done something with
$objRecipient and now it can't be passed back to MAPI. (I have tried all
sorts of stuff like casting it, actually creating $objRecipient inside
getshareddefaultfolder but PowerShell is to clever to fall for tricks like
that.
In funny that this has occurred when I'm using V2 as Bruce wrote (and times
do change) "Support for COM in the first version of PowerShell is very good
but not great. In part this is due to the fact the .NET's support is for COM
is very good but not great either. There are a few problems that you may run
into when using COM from PowerShell". (p417) on page 415 he writes "we're
working to fix this in a future releases as much as we can"
(Before anyone flames me I know I have joined up two seperate quotes by
Bruce about COM I'm not trying to put words in his mouth, I'm mentioning it
becuase I find it pretty funny that when it gets tricky and I go to my bible
for help, I'm clearly warned that I'm shark infested waters).

So I have a work around:
$sc = New-Object -ComObject ScriptControl
$sc.Language = 'VBScript'
$sc.AddCode('
Function GetCalendar(byRef objNamespace, byVal strUserName)
Dim objRecipient, objCalendar
olFolderCalendar = 9

Set objRecipient = objNamespace.CreateRecipient(strUserName)
objRecipient.Resolve
If objRecipient.Resolved Then
Set GetCalendar = objNamespace.GetSharedDefaultFolder(objRecipient,
olFolderCalendar)
End If
End Function
')
#and then later:
$vb = Call-VBScript
$objCalendar = $vb.GetCalendar($objOutLookNamespace, $User)

#Check what you have got back by throwing it at PS
$objCalendar


So my question for the members of this forum is do you have any commnets or
thoughts? Do I really need to use VBScript to slove this problem or is there
a way to get PS to not mangle my recipient object?