I like powershell for its powerful one-liners. But as soon as it comes to writing good scripts, it is too inconsistent, from the system engineer point of view: commands should be intuitive and stable: a piece of code should behave the same way in any part of the code, which is not the case.

Examples?

In VBScript, you could use the WScript object to know command line arguments etc.
In powershell, you can use $args BUT only in the main script: if you move the code to a function, $args now has the arguments of your function arghhhhhh!

function listParams ($info){        foreach ( $p in $args ) {          "Parameter $p received"          }           }

Try to pass these command line arguments to your function, like in

function listParams2{ param ([array]$arguments)        foreach ( $p in $arguments ) {          "Parameter $p received"          }           }

listParams2 $args
and your internal $args is working as if it were the external one (of course, this limits your freedom to pass the arguments you would consider necessary for intuitiveness and usability of the function).
Now try
listParams2 $args, 'extra'
and guess what, your former array of args has become $args[0], while extra has become $args[1]: the function code is now behaving foolish!

The same kind of mess occurs with invocation info: different output when code is moved from main to function
function demo() {"in function"; $myinvocation}
"script"; $myinvocation
demo
There is no reliable member that could tell you what is the script name etc.

Also everything should be pipelineable, major feature of powershell, but I cannot pipe export-csv to a filter that would convert the commas to semicolons: sorry us-men, we are using a semicolon here in Belgium.

My conclusion: Powershell language is not consistent, and not mature, and certainly not yet well designed for use by "stupid system engineers" (in the sense of KISS) instead of "genius programmers".
Problem might come from powershell design: attempting to provide the same object hierarchy for writing cmdlets and scripts. A separate object hierarchy should be available to system engineers, with globally useful informations, at script level instead of at invocation level.

Long live the next version!

Look at the event log, there is a warning:

Event Type:    Warning
Event Source:    Visual Studio - VsTemplate
Event Category:    None
Event ID:    1
Description:
The Visual Studio template information is out of date. Regenerate the templates by running 'devenv /installvstemplates' or reinstalling Visual Studio.  Note: corrective action requires Administrator privileges.

I ran the command and it was fixed...