When I was working at Sun, you could set PATH to include various *bin directories in various different orders to get an environment that met the requirements of several standards including (but not limited to) SVID3, XPG3, XPG4, XPG5, SUSv1, SUSv2, each of the revisions of the POSIX.1 and POSIX.2 standards (and most of the other POSIX standards except for POSIX.3), and also some versions of BSD and UNIX System V.

I make no claims about what has happened to that guaranteed backwards compatibility between releases since Oracle bought out Sun. (It may still work, I just don't know.)

If you don't consider shell and awk to be programming languages, the POSIX standards do still provide the C programming language. The current version of the POSIX standards are built on top of the 1999 ISO C Standard. The next revision of the POSIX standards will be built on top of the 2011 or 2017 C standard (depending on whether the Austin Group or the ISO C committee gets their next revision ready first. At one time there were POSIX working groups working on Ada and C++ bindings to POSIX.1, but those groups are no longer active. The Austin Group does still work closely with both the ISO C and ISO C++ working groups and although there is no C++ compiler specified in the POSIX.2 standard, the ISO C++ standard libraries are intended to be fully compatible with the POSIX.1 standards.

I was once offered up as a sacrificial lamb to attend some meetings helping to define standards for the Linux operating system. I was immediately deemed to be an enemy of everything that committee wanted to do. I believed that standards were created to help users write portable code; everyone else in the room thought standards were written to constrain operating systems development. Where the SVID, XPG, SUS, and POSIX standard specified requirements that conforming operating systems had to supply; the LSB (Linux Standards Base) went a different way. The LSB defined the names of some functions that the Linux operating system had to supply, but only gave very brief descriptions of what those functions did. The definition of how those functions behaved is defined by the source code for the Linux operating system; not by any document that an applications programmer could use to determine how to write a portable application that would run on any Linux system. If you write an application that conforms to the LSB and it works on one Linux system today, there is no guarantee that it will work on any Linux operating system tomorrow.

That was twenty-five years ago. Today, some Linux vendors actively participate in the Austin Group and try to mostly comply with POSIX requirements. (Note mostly; not completely. No Linux vendor has gotten a POSIX or UNIX certification demonstrating that their implementation passes the verification suites testing conformance to the POSIX standards nor the Single UNIX Specifications yet.)

Note that all of the above is my own biased opinion. Other people may well have different opinions.