NFD

Sounds reasonable to me.

This could reduce confusion for new users and reduce the need to learn multiple commands

This claim needs to be proved by a user study or survey.

ip did a good job as a combined tool.
Its syntax mostly uses positional parameters, with an extensive online help command.

netsh for Windows and asterisk are also good combined tools.
They are like command interpreters to control all aspects of Windows network drivers / the telephony server.

ssh-keygen is a not-so-good combined tool.
The feature is entirely selected by named flags, and I had to look at manpage every time I need to use any parameter.

We could make nfdc like the good combined tools, but it requires changing command syntax (but old syntax can be accepted) and major refactoring, and would become a much larger Task than just combining. Merely combining the tools doesn't have much value.

https://gist.github.com/yoursunny/89de673e0811fecdf54985bf519803d2/057412b85da47b27032e121db97404a87b0fb136 has a design for the interactions and input/output formats.
I think that's the way it should be.
Full implementation of this design is estimated to be 24 hours, but it can be done in stages.

20160809 call Alex approves note-4 design.

I like the command line syntax, it is uniform and easily extensible. It seems to be modeled after tools like ip and iw, which I consider well-designed.

I'm questioning the need for an interactive mode though... do we really need it? how much typing would it save? My guess is very little. Command completion doesn't require an interactive mode, bash and zsh support programmable completions and we could implement completion scripts for them.

In any case, if the interactive mode is implemented, I suggest not to reinvent the wheel, and use a library such as GNU readline to support proper command line editing, history, and completion.

Wrt the output format: how does the above design relate to feature #3444? Should we have an explicit flag for outputting in a stable and parseable format, e.g. --machine-readable, or --porcelain à la git? Given that we already have optional XML output for status, the formatter component should already be modular, no? Someone may even want to add JSON output at some point...

The command line syntax is modeled after ip and nmcli and netsh.

I'm questioning the need for an interactive mode though. Command completion doesn't require an interactive mode, bash and zsh support programmable completions and we could implement completion scripts for them.

The design has interactive mode, but its implementation would be lower priority.

And yes, bash completion is an alternate to interactive mode.

Wrt the output format: how does the above design relate to feature #3444? Should we have an explicit flag for outputting in a stable and parseable format, e.g. --machine-readable, or --porcelain à la git?

It's premature to define a stable output format, because fields returned from commands and datasets change from time to time.
A syntax that is both human-friendly and machine-readable should be good enough; it's not guaranteed to be stable between versions, but it's easier to parse than the old format which has whitespaces everywhere.

https://gist.github.com/yoursunny/89de673e0811fecdf54985bf519803d2/34806a5e9876ed03f00c03e605893ebe728c1dca renames fib-entry list to fib list, and also corrects a typo.

What's left to do here?