Help subcommand behaves different than help flags when App::replace is used

[nickelc]

Using clap master

Code

use clap::clap_app;

fn main() {
    let app = clap_app!(prog =>
        (replace: "install", &["module", "install"])
        (@subcommand module =>
            (@subcommand "install" =>
                (about: "Install module")
            )
        )
    );
    app.get_matches();
}

Steps to reproduce the issue

1. Run cargo r -- install --help
2. Run cargo r -- help install

cargo r -- install --help Output

prog-module-install 
Install module

USAGE:
    prog module install

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

cargo r -- help install Output

error:  The subcommand 'install' wasn't recognized

USAGE:
	prog help <subcommands>...

For more information try --help

I expected the replacement of help install with help module install

[pksunkara]

I am still deciding whether this is intended or not. replace is similar to aliases but for more args than just one.

[pksunkara]

@CreepySkeleton Need your opinion on this.

[CreepySkeleton]

My opinion is that replace was a badly designed feature. Something that OP described (cross-level subcommand aliases) was the reason replace was added in the first place, and while it does kinda solve the problem, it adds more problems (help messages don't mention it at all and there's no way for them to do so, malfunctioning help subcommand) and it doesn't quite blend with the rest of the machinery (essentially being a C-like dumb preprocessor the rest of clap isn't even aware of).

I think the solution here is to develop a working cross-level aliasing mechanism (and possibly ditch replace but that questionable).

[epage]

In case people want history, replace was added in #1697 to resolve #1603

[epage]

Cleared the milestone since it looks like we are punting on this by putting App::replace behind a feature flag. See #2836

[epage]

Cross posting from #2836 for greater visibility

Due to the lack of interest on this tracking issue, I'm considering removing this unstable feature.

Any concerns people want to raise?