No, and in many cases, an executable can't even run on the same OS of a different version due to changes in the kernel.
A simple example that I ran into the other day: the
dmesg command on OpenBSD outputs the system message buffer, which is where all the kernel's messages goes (boot info etc.). I recently recompiled the kernel, and suddenly the
dmesg would come back saying
dmesg: sysctl: KERN_MSGBUF: Cannot allocate memory
This was due to not recompiling the user-land utilities, and
dmesg, although "working" in the sense that the executable file was recognized as such, could not perform its task (due to changes in the kernel code).
dmesg from a previous version would not "work" on a later version of the OS.
EDIT (from comments, with additions)
Think of the system calls of the kernel as an API. What would it mean for the API if one couldn't change it, or if one needed to maintain compatibility with previous versions all the time? It's not a design flaw, it is how software works in general.
You can't expect to run code compiled against one API version to work with any other version of that API. As an API/kernel developer, you would become more concerned about breaking backward compatibility than about adding to and improving the operating system.
Luckily, most software on Unix systems are designed according to the POSIX standard, which means that the source of the executable is transferrable between system types and will compile and run almost anywhere. The issue of binary compatibility between Unix platforms only becomes an issue when
- Non-POSIX extensions are needed, and
- The source code is closed-source.