1. They commands I listed seem like "inherently multi-tool" commands because they've been refactored into multi-tool commands. ip is (mostly) a refactoring of ifconfig(1), but also of ethtool(1) and arp(1) and a few other things. A proper multi-mode refactoring of ps(1) would integrate overlapping utilities like pgrep(1) and fuser(1)/lsof(1), and then split those back down along separate lines.

A proper multi-subcommand refactoring of tar, I would think, might involve an interestingly different usage—a "fluent OOP interface" involving either a series, or pipeline, of invocations, all involving tar subcommands. For example:

tar manifest create --new-root=/ . | tar archive assemble --extended-attributes --timestamps --compression=lzma > foo.tar.xz

or, equivalently:

tar manifest create --new-root=/ . > foo.manifest
tar archive new --extended-attributes --timestamps --compression=lzma > foo.tar.xz
tar archive insert foo.tar.xz foo.manifest

then, later:

tar manifest read foo.tar.xz | grep -E '...' | sed '{ ... }' | tar archive extract foo.tar.xz

Using some file-descriptor introspection trickery, none of the steps except for the last one would actually have to stream bytes through them.

2. One interesting thing about ps is that it takes two separate sets of switches—BSD switches and GNU switches. Given that any given user will only want to use one or the other, these two interfaces should be broken into two utilities (likely using argv[0] detection, like gzip(1) and zcat(1)), with separate man-pages. Setting which one plain "ps" means when ps is called TTY-interactively should be a configuration-file thing.

3. Look at the man-page for GNU coreutils ln(1) or cp(1). They're messes of compat-switches, and compat-switch aggregates, aimed at allowing you to reproduce the default behaviour of the OS you're used to on any-and-every OS you can compile coreutils for. This configuration doesn't belong in argv[]; it belongs in a ./configure script, or in a ~/.config/coreutils/ui-rc file. (Some of the switches are maybe for things you might want to do even in your initrd before you've got the rootfs mounted; those are what env-vars are for.)

4. rsync(1) has options for copying ACLs, copying Extended Attributes, "handling sparse files efficiently", and so on. rsync should just try to do these things automatically, and fall back to not doing them if the source or dest doesn't have support for them. There's no use-case where both the source and target support EAs but you don't want them copies. There's also no use-case where one or the other doesn't support EAs and so you want to fail the sync instead of copying. There's no need for these switches, just like there's no need for an FTP PASV switch. It can be detected.

---

As an aside:

> not knowing that GNU and at least one BSD tar know how to automatically select compression format in at least some cases

For extraction, sure. But why not for creation? RAR and Zip can pick the best compression they "know how to" do at the current moment, and offer compression speed/quality presets that actually involve picking different algorithms.

The real confusion over tar's compression switches is more fundamental; it comes from the fact that a tar archive is "wrapped in" an arbitrary compression-container file-format, without there being any standard for those to allow you to detect something as a "gzipped tar" rather than "gzipped opaque data", and thus the inability of tar, or your OS, to recognize an "[unknown compressor]ed tar" file.

The gordian knot of tar(1)'s switches is for tar—already having treated the compressor as a subprocess rather than a pipe-destination for a long time now—to just begin adding a "this is a tar archive with a compressed stream of archive files inside it" header to the outside of the compressed stream. Even though full backcompat is still possible after defaulting to such a change (user pref files! env vars! in-file hinting that the previous binary can recognize!), everybody's too lazy to want to make that sort of change.