I believe you'll find that the standard behavior under Linux is the opposite of what you claim:
[~]$ ssh -o -Y email@example.com
command-line: line 0: Bad configuration option: -y
The `getopts` command in Bash works the same way:
[~]$ set -- -A -B
[~]$ getopts "A:B" opt; echo $opt; echo $OPTARG;
As does `ls`:
[tmp]$ touch -- -t plain
[tmp]$ ls -t
[tmp]$ ls -I-t
[tmp]$ ls -I -t
(Tested in Debian Linux. The -I (--ignore) option to `ls` specifies a glob pattern to skip in the output.)
Even the test program in the getopt(3) manual page you linked to processes "-t -n" as a single option "-t" with argument "-n". The documentation simply states that "optstring is a string containing the legitimate option characters. If such a character is followed by a colon, the option requires an argument, so getopt() places a pointer to the following text in the same argv-element, or the text of the following argv-element, in optarg." There is nothing to indicate that following argv-elements starting with a dash are treated differently.
Options with optional arguments (like Perl's "-i" option) are not allowed to be split, so in this case "-A -B" would indeed be treated as two separate options. However, this would cause "-A B" to be processed as an argumentless "-A" and a separate positional argument "B" (equivalent to "B -A"), and not as a substitute for "-AB".