I've been a heavy PowerShell scripter since version 2.0 and managed thousands of Windows servers of every version all the way from 2000 up to the latest and greatest and doing a lot of C# direct access to the framework and usage of all the objects in the framework along with win32 direct DLL access for certain system level calls.
Prior to that I was a very heavy Batch/Command developer with natively compiled GNU/Linux Utils from GnuWin32 and then native GNU Utils commands. While at the same time writing some bash scripts for all kinds of Red Hat and Debian based Linux distributions that I was administering also for many servers in the large Enterprise environments.
Inconsistent Cmdlet Implementations
I agree with you that there is some weirdnesses with Powershell but most of the problems I found is like you said the inconsistency of how certain cmdlets work and who developed since some of the standard features such as -ErrorAction Stop do not work on some command that's from different modules and developers who ignored parts of the core development ideologies of PowerShell or they didn't implement enough functionality to be able to nest those commandlets inside catch/throw/finally error catching logic to stop scripts that end up with a failure result in a throne error exception.
Many of the commandlets by Microsoft that were originally developed had a very high standard of compliance to the Powershell, advanced functions, implementation of all the core and comment switches and they worked great. But as time moved on many of the third party modules and snap-ins didn't follow those practices. So you end up with a very strange behavior or lack of functionality for trying to catch errors. And I've had to work around a few problematic ones over the years.
PS Snap-Ins to Modules
There was a big migration right around version 3 up to version 5 of Powershell of third party functionality moving from snap-ins to modules and that broke a lot of stuff and a lot of scripts and a lot of remoting functionality broke especially for trying to administer old Exchange servers going into the new Exchange servers. Which required a lot of rewrites and a lot of new authentication logic and command remoting functionality was completely changed and how it functioned.
Some of those created breaking changes and caused pain and environments that didn't have the latest and greatest things. So you kind of got stuck in this world of trying to execute old 32-bit. PS snap-ins and DLL libraries into a 64-bit world that is now running on modules and version 5 PowerShell.
PowerShell v5.1 Schism to v7+
The very large change and schism of the entire language between 5.1 that comes natively with Windows server all the way up to 2019 if I remember correctly and now the separately installed Powershell 7 with a whole new executable to call and enough little changes to the language has caused a massive schism of scripts. Powershell scripts written for version 2 all the way through version 5. Work pretty much seamlessly with very little adjustment. But trying to get anything working from version 2 through 5. On version 7 ends up with the roadblocks and showstopper errors and requires almost complete rewrites.
There are many limitations and bugs left in Powershell version 5.1 that was native to a lot of the servers and it was installed by default as part of Windows remote Management framework WRM and it became the de facto version to write Powershell up to because you could install WRM on any server of 2003 all the way to 2019 and later. So a lot of scripts and plugins and modules were written exactly for version 5.1.
None of the bugs that exist with Invokeâ"RestMethod of not being able to access the headers in order to make sure some weird REST API authentication that is header based is actually correctly functionable or when APIs give you the pagination information inside the header become a problem and you end up having to Invoke-WebRequest and then manually access the headers and the body and parse the body as a JSON object which is at least possible.
Under Powershell version 7, now you have the ability to access the headers from the REST API commandlets but now you have to change your whole script to run under version 7.
Power shell My Favorite Scripting Language
I have to say that Powershell is still by far my favorite scripting language to administer large Enterprise systems and I have done some amazing scripts in the thousands of lines with a lot of care and capture of errors and unusual situations and have gotten some amazing results. Even multi-threaded and multi-process like remote execution and then collapsed to a single result set object structure into single output and have been using that for over a decade now to manage thousands of servers.
Powershell is by far my favorite scripting language because it is object oriented and when I need to get little pieces of things it works great. If I need to deal with rest API or direct win32 dll access or access databases or other type of Enterprise storage systems or interface with large Enterprise or third party networking systems or storage systems or virtualization systems or any type of other systems, Powershell makes writing scripts that are robust very easy .
If you understand Powershell and you understand the C# framework and you understand how pipelining works from Linux and how you can incorporate it into your Powershell for fall through functionality with filtering and object molding you can do some amazing things.
Leaving Job to Script in PowerShell Again!
One of the reasons that I am leaving my organization at which I have been 16 years is that I have been moved to a team to do high-level analysis and away from hands-on scripting and PowerShell work. So now I'm looking for any other organization that is a very high PowerShell user in a large Enterprise environment so I can go back to hands-on keyboard writing some amazing scripts because frankly writing PowerShell script is like creating and solving your own puzzles and once you understand the environment and the universe you're working in then it is very pleasurable to do the work because you understand the boundaries and the limitations within the systems and the entire environment.
Does anybody need up high level PowerShell developer in a very large Enterprise environment of thousands of servers that need automation, scripting and integration with all the other third-party systems?
Because I'm actively looking now for something now and I want to offer my skills and help to any other large organizations that need automators and scripters and integrators.