What should it fix? Why it matter?

Quoting part of my recent mail on src-committers@:

But since there are uses of 'freebsd32.h' unconditionally on all platforms (in 'kern_umtx.c' at least), and since we also check sizes of structures, I think we should at least ensure that 'struct foo32' on a 32-bit arch is type compatible with 'struct foo' on the same arch.

And I do not see that as unsustainable, on the contrary, it is very simple to achieve: Have all 'foo32' types boil down to exactly 'foo' on 32-bit architectures, which is what we are supposed to do already for structures by compat' design. 'freebsd32_uint64_t' you introduced typically supports that. That's the why of https://reviews.freebsd.org/D55283, which fixes commit 87632ddf67b0 ("openzfs sys/types32.h: use abi_compat.h for time32_t") where defining 'time32_t' to 'in32_t' for 32-bit architectures appears to have been an arbitrary choice of yours, which in practice by luck does not change the whole size of 'struct ffclock_estimate32' because 'struct bintime32''s one does not change either as even if its field 'sec' was incorrectly sized after you commit (this is what D55283 fixes), the 'frac' one is 64-bit and 64-bit aligned on all non-x86 architectures so its offset in 'struct bintime32' stays the same.

So, again, I think the rule of thumb should just be: Type 'foo32' is compatible with 'foo' on 32-bit architectures and has same alignment. That's the only thing that makes sense if 'struct *32' are visible on 32-bit architectures.