Almost powershell's bundled cmdlets don't rely on powershell engine.
So, if powershell team separates bundled cmdlets from powershell environment, we can get following benefits.
OneGet can implement it, I think.
__more rapidly updates__
Currently bundled cmdlets are in powershell, so we must wait for next powershell (== next OS) in order to update cmdlets.
If we can get updated cmdlets from OneGet, we don't have to wait.
This benefit is specially remarkable with security updates.
__more flexible backport__
Even if bundled cmdlets don't rely on new powershell engine, if new powershell doesn't support Win7, we can't use them on Win7.
If we can get updated cmdlets from OneGet, we can use them without new powershell.
(and, new powershell / PS team don't have to support old OS ;-)
Naturally, some cmdlets would rely on powerhsell engine.
So powershell team would need to pick out them.
So, if powershell team separates bundled cmdlets from powershell environment, we can get following benefits.
OneGet can implement it, I think.
__more rapidly updates__
Currently bundled cmdlets are in powershell, so we must wait for next powershell (== next OS) in order to update cmdlets.
If we can get updated cmdlets from OneGet, we don't have to wait.
This benefit is specially remarkable with security updates.
__more flexible backport__
Even if bundled cmdlets don't rely on new powershell engine, if new powershell doesn't support Win7, we can't use them on Win7.
If we can get updated cmdlets from OneGet, we can use them without new powershell.
(and, new powershell / PS team don't have to support old OS ;-)
Naturally, some cmdlets would rely on powerhsell engine.
So powershell team would need to pick out them.
