[flohofwoe]

Splitting fat vertex component data into multiple streams also often makes sense in rendering engines (e.g. not all vertex shaders might need all vertex components). Strict SoA or strict AoS hardly ever makes sense, but an 'inbetween' approach often does (maybe call it SoAoS) - and this should be possible just fine with Zig's comptime approach, e.g. only apply the SoA transform to the toplevel items of a struct.

As for CPU-side vector math:

Zig already has a @Vector type (which will probably be renamed to @Simd) and it will get a builtin matrix type. With those two things, the main reason for operator overloading in game/rendering engines is pretty much handled via builtin types.