There are a couple of rare edge cases where polyglot programming comes in handy. With polyglot programming, the source code can be understood by multiple languages. Usually, this is done for some kind of backwards-compatibility.
For example, we can create a Perl script that can also be invoked as a shell script, which has some uses if the system doesn't support the shebang line properly:
#!/bin/sh
#! -*-perl-*-
eval 'exec perl -x -wS $0 ${1+"$@"}'
if 0;
(from perldoc perlrun)
It is also somewhat common for C++ libraries to express the externally-visible interface in a C-compatible manner. This allows the library to be used more easily. While C and C++ have similar syntax (and C++ was based on C), they differ in a couple of subtle points that can make it difficult to use C++ code from C.
Within C and C++, there's also a lot of clever use of the preprocessor to use compiler-specific features portably. If we argue that GCC's C is a different language from Visual Studio's C, a program that compiles under both could be considered to be polyglot.
Other than that, polyglot programming in production is pointless. You know what compiler or interpreter you'll be using, so you only have to target that.