Comment 1 by mitchell.hashimoto:

Sorry, I filed this as a defect when I meant to file as an enhancement. I can't find a
way to modify it now. Sorry!

Comment 2:

Future senario:
I'm dumb and I have passed a wrong (non existing) flag to a command. I expected the flag
to perform something, but I'm using the result of the command (to a file, redirected
stdout) only few (painful/expensive) steps/pipe stages later. Only then I'm surprised
the action was not performed, because the flag I provided was ignored. In the worst case
I've already deleted/overwritten/lost the original source data and cannot go back to
square one.
Today's scenario:
The command fails immediately with writing a problem to stderr and returning a failure
exit code. This saves me from detecting the problem too late.

Comment 3 by mitchell.hashimoto:

I absolutely agree with you. I'm not saying to make this a default, just an option.
And my only use case is for multi-pass command-line parsing. I ALWAYS want a bad flag to
fail in the second pass. 
My scenario in your world:
So one of the flags I need in the first pass is "-debug". Let's say the user fat fingers
it and types "-debg". The debug mode won't be enabled because it won't be found on the
first pass. No error occurs. The second pass happens with errors on and then says
"unknown flag -debg. No problem.
Of course the existence of the flag makes it possible for people to shoot themselves in
the foot, but why would people enable it without legitimate reason? If it is off by
default (which I believe it should be), then they would be consciously making that
mistake. There are many ways a programmer can shoot themselves in the foot, but I
believe there are legitimate reasons for it.

Comment 4:

I don't like this proposal but worse, I don't know how to implement it because of
boolean flags. If you don't know the type of the flag, and for an unknown flag you never
know it's type, in general you can't parse the command line.

Status changed to WontFix.