This is not a bug, but an enhancement request -- I'd like to be able to turn off this behavior.

Right now, Click allows a group name and a command name to be separated using the -- separator.
I think this is confusing, and I would like it to raise an error in my CLI.

To explain and provide an example, imagine a command group foo with a command in it named bar.
You can write

$ foo bar --help

and things are happy.

You can also write

$ foo -- bar

and things work fine.
This behavior makes sense in my head, because bar is a positional argument to foo in a sense, but things are about to get messy and weird.

$ foo -- bar --help

This works, producing help output, and it really looks to me like it shouldn't. I guess the parsing for bar comes into play when it's read by foo and -- is just forgotten? I'm not sure.

I would like to entirely disable the usage of -- within the command tree. That is, I think it should be usable after a command name, but not between a group and a command.
So, foo -- ... should be entirely disallowed because it's a group. The only reason to use -- is to pass things like --help as arguments, and the parsing behavior here is confusing.
I don't see a viable use-case for writing foo -- bar ... over foo bar -- ....

I could see this being added as an optional behavior, since making it the default will potentially break existing scripts.
In the meantime, is there some way that I can disable this for my own application in Click 5 or 6?
I'm also happy to write this and submit a PR, if I can get a little bit of direction on (1) where I should be looking to customize the parsing and (2) whether or not this is a feasible small change (vs. uprooting a lot of well-established code, which I'm somewhat averse to).