Eh, not really. Consider readv as specified by POSIX:

ssize_t readv(int fildes, const struct iovec *iov, int iovcnt);

where POSIX specifies that struct iovec has at least the following members:

void   *iov_base  Base address of a memory region for input or output.
size_t  iov_len   The size of the memory pointed to by iov_base.

That unambiguously states that typeof/sizeof/alignof(((struct iovec *)0)->iov_base/len) are that of void */size_t, not my_magic_64_but_32_ptr/my_magic_64_but_32_size_t. But yet they need to do something special. Now maybe you do some horrible thing where you pretend to C that they're the 32-bit types, but really under the hood they end up as the 64-bit ones, and pray people aren't doing things using those types (e.g. typedef typeof(((struct iovec *)0)->iov_base) my_void_ptr; my_void_ptr *p = malloc(sizeof(my_void_ptr)); *p = ... would presumably get very out-of-bounds-y very quickly, but by the letter of POSIX should be completely legal).

Maybe though in practice that's all ok, and you even go as far as making sure they're magic for the purposes of C++ overloading, templates, name mangling, etc., so you can't tell they're not the 32-bit ones. But then msgsnd and msgrcv (NB: *not* the more typical sendmsg and recvmsg) come along and make everyone even sadder. Take msgsnd for example (msgrcv is the same fundamental API); POSIX defines it like so:

int msgsnd(int msqid, const void *msgp, size_t msgsz, int msgflg);

where it has this to say:

The application shall ensure that the argument msgp points to a user-defined buffer that contains first a field of type long specifying the type of the message, and then a data portion that holds the data bytes of the message. The structure below is an example of what this user-defined buffer might look like:

struct mymsg {
    long   mtype;       /* Message type. */
    char   mtext[1];    /* Message text. */
}

There's no fudging with magic types in system headers you can do to get around this one. As a programmer POSIX says you are the one who has to write the type of the first field as long, in a structure passed to the kernel. So you really are stuck with having the kernel know to differentiate x32 from standard x86_64.

Also mmap and things like shmat need to return pointers in the first 4 GiB of the address space, but I suppose implicitly adding MAP_32BIT to every request for certain processes isn't as heavyweight as having separate types floating around.

As for why I know this? Because Linux got it wrong and used the 64-bit syscall msgsnd/msgrcv. It broke fakeroot on x32, I went down the rabbit hole, and submitted https://lore.kernel.org/all/20201012014837.14305-1-jrtc27@jrtc27.com/ to fix it. Seems that never got merged in the end though so it's still broken... just shows you how little x32 and/or those APIs are used.