Why are Linux system call numbers in x86 and x86_64 different?

As for the reasoning behind the specific numbering, which does not match any other architecture [except "x32" which is really just part of the x86_64 architecture]: In the very early days of the x86_64 support in the linux kernel, before there were any serious backwards compatibility constraints, all of the system calls were renumbered to optimize it at the cacheline usage level.

I don't know enough about kernel development to know the specific basis for these choices, but apparently there is some logic behind the choice to renumber everything with these particular numbers rather than simply copying the list from an existing architecture and remove the unused ones. It looks like the order may be based on how commonly they are called - e.g. read/write/open/close are up front. Exit and fork may seem "fundamental", but they're each called only once per process.

There may also be something going on about keeping system calls that are commonly used together within the same cache line (these values are just integers, but there's a table in the kernel with function pointers for each one, so each group of 8 system calls occupies a 64-byte cache line for that table)

See that answer to the question "Why are the system call numbers different in amd64 linux?" on Stack Overflow.

To sum it up: for the sake of compatibility, the system call list is stable and can only grow. When the x86 64 architecture appeared, the ABI (argument passing, returned value) was different, thus the kernel developers took the opportunity to bring changes that had long awaited.