Generally people don't look at the output of the compiler, but the output of the compiled program. New compilers for an existing language generally have to reproduce the behavior produced by the existing compiler; they can't, for example, return the last-evaluated value in "a && b" instead of 0 or 1, even though that is almost always more useful. (You could say, "Well, they're just complying with the standard," but that's backwards; clone C compilers existed years before any standard, and the standard codified the behavior they all found sufficiently important to clone, as well as improving the language in some ways.)
It's true that new compilers often try to produce the same effect with more efficient generated code, just as web sites might strive to produce the same visual output more quickly.
Generally people don't look at the output of the compiler, but the output of the compiled program.
This is wrong because you are viewing the task of a compiler in terms of the result of the compiled program. A compiler is simply a translator from one language to another. The result of the program is the result of an interpreter running the code, not the compiler. Deviation from correct output in the compiled code is not only not allowed, it is deemed a bug in that code.
The unique part of different compilers is not the output of the compiled code they produce but the compiled code itself. All compilers should produce code that produces the same result if they are taking in the same input, by definition.
It's true that new compilers often try to produce the same effect with more efficient generated code, just as web sites might strive to produce the same visual output more quickly.