Insane SCVMM and Hyper-V - no API for remote access

For any enterprise product one of the fundamental facets is its public [programmatic] interface using which other products can interact with it or users can write scripting etc. 100% marks in this regard to VMWare vCenter which has a very well thought through web interface based on SOAP. Top that with client specific bindings in Java, .NET, Python etc and you are covered. There is no talk/bothering about what OS you are using on the client in order to connect and program the enterprise service.

Enter the world of 'insane scvmm' - things are not like how they should be and even worse, they are no where close to being sane. SCVMM is Microsoft's flagship product in v12n management and squarely positioned to compete with VMWare's vCenter. But guess what, there is no public API to SCVMM that's programmable from across different OSes. This is because the primary and only API available to program SCVMM is a powershell based. This has few major problems

1. Powershell is not available on non-Windows boxes. I know folks out there think powershell is universal et. al. But there is no credible and corporate-backed implementation of powershell on linux, solaris etc. Without this, no entperise wants to rely on the stack
2. The powershell documentation for scvmm is a nightmare to comprehend. Take 'New-VM' as an example - this cmdlet is used to create a new vm. It takes literally 100+ parameters across different variants of it. The parameter list is flat and available valid combinations and permutations are hard to deduce. Plus the documentation is not even available online in an html form so that it can bing-ed or google-d. It's only in MSWORD or PDF form.
3. Even in the documentation there is no place for me to just understand the entire set of properties that make up an object, say vm. There is only set-vm which has a set of properties that can be set- with usual quirks of valid combinations etc. There is a get-vm but that has no info about all the properties. Contrast this with vcenter's web-published documentation of its awesome object model.
4. Even if I accept client-can-only-be-on-windows apathy, the way to get the client SDK setup is clunky. I have to install a full-fledged admin console - which is a heavy-weight UI just to get 1 or more DLLs that have the scvmm powershell modules. Contrast that with vcenter which has a web interface to download the WSDL.

Coming to HyperV, this is even worse. The only interface to HyperV is WMI-based and that too the client MUST be local. To enable a remote client, one has to go through a laborious set of configuration changes, security anti-patterns etc so the client (again only windows based) can be on a different box. The interface is totally different and disjoint from that of SCVMMs. Contrast this with ESXi - the data and programming model for ESXi is exactly identical to that of vcenter. In fact any client that's written against the interface can work equally well when pointed to esxi or vcenter - this is holy grail!

We use .NET reflector and without this, it is simply impossible to write any non-trivial client for programming scvmm. Reflector disassembles a .NET assembly hence giving us insight into the actual model. We deal with SCVMM APIs in and out very deeply - many times I literally get the feeling of sickness looking at the api maturity, crazy constructs etc, especially relative to vmware centers APIs. God bless me and our team dealing with this insane product!