One ongoing annoyance I have with commandline tools is that getting a single new tool requires learning a new vocabulary for using that tool. Sure, there are putative standards and if you've dealt with UNIX/Linux systems before you can trust that certain ported tools will use particular conventions, but that doesn't help with the nonstandard ones.
I'm of course eventually going to use this as an opportunity to mention why I really like MSH, but today I just want to talk about the current console problems. Talking about MSH will come later because the effect of MSH will be complex. If you're wanting a word bite on it right now: in theory MSH can completely resolve this problem; in practice it won't guarantee everything but it will probably shrink the problem by two orders of magnitude.
To illustrate how bad the conventions and names nightmare can be, let's look at integrating a set of new tools into your standard console toolbox. It's only by looking at commands taken together that the annoyances become apparent.
Let's say tools you're adding tools dealing with 6 important object types: services, xml structures, users, files, permission structures, and printers. Let's also say that there are 5 different operations done on each object by the various tools - in other words, you have 30 different console utilities. (This is a little extreme; some tools provide multi-role use allowing you to specify a parameter that switches modality, so it COULD be as little as 6 tools - but not likely). Let's also say these operations are the same 5 for all object types: listing, setting/saving, copying, moving, and deleting.
At this point, we already have some complications. You need to "know" the names to invoke the tools or even find them. Do they use the same name form? Is it a bare object name? A bare operation name like "duplicate"? Are they abbreviated? How do they concatenate the operation and the object name, if they do at all? I've seen cp, copy, cpy, dup, duplicate, and even newfrom as synonyms for copy. If you don't have all of the tools for an object set from the same source - certainly possible - it can be even stranger. For example, I have 4 standalone commandline cd-burning tools that I know of in my \bin folder: CreateCD, cdburn, oscdimg, and hd2iso. I say that I know of because that bin folder has many files and some unusual names; I originally overlooked hd2iso for example. You may get lucky and have some standard names if tools come in a set; then again, you may not. If you're working with services, you've used the "net" command for start, stop, pause, and resume on a service; but disabling or enabling takes switching over to sc.exe with a completely distinct syntax. The worst case scenario is that you have to "know" 36 different words: 6 object types and 5 distinct operation names for each of the objects. In practice, it would be less since you would have some contextual clues that help you see a pattern. In fact, if they're distinct tools, you could even try renaming them to fit a pattern, something I've done for convenience before. (If you try this, be warned there are LOTS of possible nasty side effects).
Setting aside command name confusion, each of these operations/commands/tools may have very distinct specialty parameters or options you may need to use. Let's take 5 things that all of these commands COULD benefit from: verbosity, help, error handling, a target computer, and an "if" mode that lets you see the effect of changes without actually committing them. If you're familiar with some tools from different environments, you know how these can vary. Again, the VERY worst case possible for intuitive use is that each tool is from a different person informed by a very different computing culture. Spelling out the obvious, we have as many as 150 distinct parameter names, and we haven't touched the behavior. Does invoking help return information to stdout or stderr? Are parameters case-sensitive? Can you provide partial parameter names? What happens if you provide a bad parameter? Does the tool stop or does it run along doing what it did before and ignore extra parameters? If it stops, does it set the errorlevel? And does it echo help info and scroll your error off the screen? (Oops, that's not a naming issue, just an annoyance). What's the character used for parameter flagging, '-' or '/'? Are values separated from parameter names by a space, a colon, an equal sign, nothing, or something else? And how do we correlate all of these with no guidance?
Chances are it isn't quite that bad, of course, since naming patterns are possibly identical in toolsets. In that case, you may have only about 6 distinct sets of parameters, and if every single one of those object-centered toolsets is complete (provides all operations you need) then you have about 30 names in 6 different naming patterns and about 30 distinct parameter names at most. It would be difficult to get the theoretical worst-case of 150 distinct parameter names (and unlikely for there to be even 30 in the restricted case); there are only so many synonyms for the word "help" in English. There are definitely 2-3 synonyms in use for most common parameters, however; and computers being literal, issues such as partial names, case-sensitivity, and parameter flag characters mean that there are likely to be multiple distinct "correct" names and therefore opportunities for accidental misuse. There is another twist as well: homographic parameters, ones that are spelled alike but have different meanings. For example, taskkill uses /F for "force" and xcopy uses /F for "fullname".
At this point, I'm glad this is a blog and not an article; I don't have to show a way to fix this right now in 3 easy steps. Later on I'll talk about some sources of this problem (there are lots and I don't know most of them) and what changes in the MSH context (a lot, although it can't directly do much about ugly legacy tools).