Support mixed case-sensitivity

[SirNickolas]

I think, apart from being case-sensitive or case-insensitive, there is a third practically useful approach: ignore case in long options but be case-sensitive in short ones. The reason is that it’s fairly common to have one-letter options that differ only in their case. I believe they should not block the ability to match long options case-insensitively.

There is a tricky point, though: how should we process --g? There are three strategies that are all sane on the first glance:

1. Be case-sensitive, despite the fact it has two dashes.
2. Be case-insensitive; if there is an ambiguity (i.e., both -g and -G exist), emit an error.
3. Be case-insensitive; if there is an ambiguity, prefer option that matches exactly.

To understand which one is better, let’s consider this scenario:

1. There is a program that has a -g flag.
2. A user writes a script that invokes the program with --G.
3. A new version of the program is released. It now understands the -G flag.

With strategy 1, the user would face an error right on the second step, thus the problem is prevented before it even appeared. With strategy 2, when the user upgrades their installation, their script will break. The program simply added a new option, and that turned out to be a backwards-incompatible change. With strategy 3, when the user upgrades, their script will silently begin doing something different.

I hope the point is clear now.