Thanks Jeffrey but most of the slides came from you!

What can I say, you've done a great job of creating a tool that puts very few limits in the way of a consultant, dev, admin or even a user creating and using scripts that makes parts of their job a repeatable process. That leaves a lot more time to concentrate on the higher level problems.
With PowerShell I like the way that learning a simple syntax (import-csv, import-xml) and using the pipeline you can create complex data driven processes.

To improve things, well a Visual Studio plug-in with the usual trimmings(intellisense, debugging...) would lower the entry 'knowledge barrier' even further.
We can use the System.Data libraries directly but how about a DLINQ like handling of data in PowerShell. Maybe you get this for free with ADO vNext, but DLINQ with Pipelines would be very powerful.

A lot of the future development path that will help the most will be external applications using PowerShell as its controllable API, the Exchange team have made a great start but I'd want products like future versions of SharePoint to do the same. Its a lot of work I know but ultimately there's no reason apps can't have a history buffer of PowerShell comands that could be cut, pasted and adapted.

Finally maybe its just me but just one issue caused me problems. Generics. The SharePoint object model has a few places that this kind of syntax is needed

SPFarm farm = SPFarm.Local
FormsService fs= farm.Services.GetValue<FormsServices>("")

I've seen no samples on generics so not sure how that can be done in PowerShell, I end up looping through the collection matching on a property, inefficient and just not pithy.

Regards,
Colin Byrne