Regarding a) and d), which I, in my madness, consider the same point - the command line environment as a whole:

I love command lines. Problem is, I grew up with AmigaOS, which had a shell and command-line utilities that were orders of magnitude more user-friendly than the Unix environment. People don't seem to realize the command line doesn't actually have to be an intensly user-hostile environment.

All Unix shells are stone-age remnants. As you said, the scripting can and should be offloaded onto other utilities that are better at it. They could also do a whole lot more to help out the user. I especially enjoy when I type the name of a directory in a shell, and it'll actually go to the trouble of inspecting it, and then sullenly declaring "foo is a directory." Yes, I know, I wanted to cd into it. Shells on other platforms have been doing that for decades when you typed the name of a directory.

The default commmand line on Windows is horrible, but 4DOS and its successor 4NT are lovely environments, that actually make work easier for the user. This is a fascinating concept that Unix shells should try.

Now, the command line flags. The AmigaOS had an OS function for reading them - it let you specify names for options, what kind of options the are (flags, strings, multiple strings...). It would also always list the options if you just put a "?" as the command line option. It would furthemore intelligently figure out when option names could be left out. It didn't use any dashes or slashes either. A copy command might have a command line template like: "FROM/M/A, TO/A". This means there was a "FROM" option that took multiple strings and was required, and a "TO" option that was required. So you could either say "copy from file1 file2 to directory", or just "copy file1 file2 directory", because it was clear from context what the options are. This is where Unix people would complain about "what if you had a file named FROM?", but of course this could easily be disambigued by saying "copy "FROM" directory". It was also up to programs, not shells, to expand wildcards, thus causing far less problems that way.

Regarding b) and c), Mac OS X has a fairly nice solution with its bundles. This is worth ripping off.

Regarding g), text editors in the rest of the world pretty much standardized how an editing interface should work, and what key combinations to use for the most important tasks (ctrl-s, ctrl-x, ctrl-c, ctrl-v, and so on) a decade or two ago. Unix text mode editors never seemed to notice.