Quant au raisonnement derrière la numérotation spécifique, qui ne correspond à aucune autre architecture [sauf "x32" qui fait vraiment partie de l'architecture x86_64] :dans les tout premiers jours du support x86_64 dans le noyau Linux, avant qu'il n'y ait fortes contraintes de rétrocompatibilité, tous les appels système ont été renumérotés pour l'optimiser au niveau de l'utilisation de la ligne de cache.
Je n'en sais pas assez sur le développement du noyau pour connaître la base spécifique de ces choix, mais apparemment il y en a quelques logique derrière le choix de tout renuméroter avec ces numéros particuliers plutôt que de simplement copier la liste d'une architecture existante et supprimer ceux qui ne sont pas utilisés. Il semble que l'ordre puisse être basé sur la fréquence à laquelle ils sont appelés - par ex. lire/écrire/ouvrir/fermer sont à l'avant. Exit et fork peuvent sembler "fondamentaux", mais ils ne sont chacun appelés qu'une seule fois par processus.
Il peut également y avoir quelque chose à propos de la conservation des appels système qui sont couramment utilisés ensemble dans la même ligne de cache (ces valeurs ne sont que des entiers, mais il y a une table dans le noyau avec des pointeurs de fonction pour chacun, donc chaque groupe de 8 appels système occupe une ligne de cache de 64 octets pour cette table)
Voir cette réponse à la question "Pourquoi les numéros d'appel système sont-ils différents dans amd64 linux?" sur le débordement de pile.
Pour résumer :dans un souci de compatibilité, la liste d'appel système est stable et ne peut que s'allonger. Lorsque l'architecture x86 64 est apparue, l'ABI (passage d'arguments, valeur renvoyée) était différente, les développeurs du noyau en ont donc profité pour apporter des changements tant attendus.