PowerShell and the current directory

Not sure how to contact anyone on the PowerShell team, so I'm posting here.  I've found what I must call a bug in PowerShell.  Here's how to reproduce it.

Start PowerShell, which will put you in $home (for me, this is H:\).

PS H:\> cd 'C:\Program Files'
PS C:\Program Files> get-location

Path
----
C:\Program Files

PS C:\Program Files> [System.IO.Directory]::GetCurrentDirectory()
H:\
PS C:\Program Files>

This behavior, if intentional, is crazy.  When you execute other programs, or (as in my case) use COM objects, they won't think the current directory is the directory that the user thinks is the current directory.

What's the deal?  Does it behave this way because PS has the concept of locations that don't actually exist (such as when you cd into the registry hive)?  If so, then shouldn't there be (an obvious) way to get/set the actual working directory, or better yet, if the "location" is an actual directory, shouldn't the current working directory be set as well?

[System.IO.Directory]::SetCurrentDirectory("C:\Program Files")

Thanks, I couldn't have figured out for myself that GetCurrentDirectory() would have the sister SetCurrentDirectory() *rolls eyes*.  I know how to work around the problem, the question is why it exists?  And if there's some reason it must exist (yeah, right) then why isn't it thoroughly documented?

I'm liking Powershell so far.  Like everything else, there's warts, but all in all it's fairly well thought out and very powerful.  But this particular behavior really baffles me.

I can see why you would think that cd would change the application's working directory.  But I can also see why the location within powershell would be different from the powershell application's working location.  To me it is more of an issue of scope than a bug.  GetCurrentDirectory is the current working folder of the PowerShell application and cd changes the working location IN the PowerShell app.

If your scenario is a bug, the running:
[System.IO.Directory]::SetCurrentDirectory("C:\Program Files")
would have to be a equivalent of running:
cd "c:\program files"
and you would expect the prompt to change as well, but it doesn't.

I would be curious to see the response from someone on the powershell team.   I would guess they made a conscience decision to leave System.IO disconnected from Mocrosoft.PowerShell.Core\Filesystem.. and I would bet that it does have something to do with the Set-Location command using providers that can be extended.  Kind of difficult to link System.IO to Microsoft.PowerShell.Core\Filesystem if the underlying provider can be changed.