Sometimes it can seem like Microsoft is deliberately trying to confuse us.
Like its predecessors, PowerShell v3 installs to %systemroot%\WindowsPowerShell\v1.0. Does that mean it's still version 1.0? Well, in a sense, yes: It's v1.0 of PowerShell's language engine, which hasn't changed much over the three versions we've had so far. Microsoft's plan is to continue using the 1.0 language engine unit they have to make some change that isn't backward-compatible. At that time, they'll come up with 2.0 of the language engine, so that the two engines can potentially live side by side.
Check the $host.version variable and you'll definitely see that v3 is installed:
PS C:\> $host.version Major Minor Build Revision ----- ----- ----- -------- 3 0 -1 -1
But that's not the only version you may have to work with. You see, PowerShell v3's actual functional code - it's true engine, if you will - can live side by side with the v2.0 engine. There are a couple of reasons for this, one of which is developers who've taken some kind of hardcoded dependency on v2, and whose code will crash or refuse to run if it sees itself running on v3. Sometimes, that isn't an indication of an incompatibility, it's just code that's checking for "2.0" and which won't run if it sees anything else. Kinda like older apps that insisted on running on Windows 2000, that had to be tricked if we wanted them to run on Windows XP.
Accessing the v2 engine is easy: Just use the -version switch of PowerShell.exe:
PS C:\> powershell -version 2.0 Windows PowerShell Copyright (C) 2009 Microsoft Corporation. All rights reserved. PS C:\> $host.version Major Minor Build Revision ----- ----- ----- -------- 2 0 -1 -1
This gives you full access to the old engine. You can use this trick for scheduling scripts, running them interactively, or whatever you like. Note that this doesn't necessarily play into the #REQUIRES meta-comment: That thing is designed to designate a minimum version of the shell. So a script indicating that it #REQUIRES version 2 will still run on version 3.
Of course, this is all subject to my standard PowerShell v3 caveat - keep in mind we're dealing with pre-release code.