Y is down in win32, as well as in css. But this might depend on each particular device and driver.

Y was down in nearly every 2D-only graphics system. That's still on the up/down axis. [Edit: If I'm being honest, disagreements between Y-down and Y-up cause me a lot more trouble than disagreements between Y-up and Z-up when handedness is the same.]

I'm okay with viewport having XY coordinate system, because viewport is inherently 2-dimensional. In fact, you can't have it in any other way, really. But why do you force this concept onto 3D?

Because I'm projecting this 3D scene onto a 2D surface.

I'm not sure where you copy-pasted this from, but "kibiword" is not a thing, the unit is spelled kiloword.

"kibi" is the SI [edit: IEC] binary prefix for 1024, analogous to "kilo", the SI prefix for 1000.

For 2D, I personally think of a traditional cell animation setup, where the camera is looking down onto the sheets.

Because I'm projecting this 3D scene onto a 2D surface.

You can project something onto XY plane or XZ plane, math works out the same. That's inner details of the renderer anyway.

Why should I as a user care about this detail if I'm describing 3d world?

"kibi" is the SI binary prefix for 1024, analogous to "kilo", the SI prefix for 1000.

Neither "byte", and especially not "word" are SI/SI-derived units, so SI standards are not applicable here.

Going on a tangent here: Computer science does not use SI prefixes. Current recommendation, as far as I remember, is to use "kilobyte" as a unit of storage capacity, which is shorthanded as "KB" or occasionally "KiB" for clarity, and always means 2^10 bytes. I can provide citations, but I'm afraid it has nothing to do with Bevy really. Edit: I vaguely remember "decimal kilobyte" being a unit, but it is rarely used, so doesn't have a shorthand.

You can project something onto XY plane or XZ plane, math works out the same. That's inner details of the renderer anyway.

I think I have been unclear. When I say I'm projecting something onto a 2D plane, I'm talking specifically about the rendering step; the only part of a 3D rendering pipeline that is not optional.

If you are in a situation where Z-up makes more sense or is more convenient to you, go right ahead and use Z-up—if you're starting from a Y-up frame, that's just one view rotation away. What bothers me is when an engine (or modelling program) forces Z-up, because then it forces having two definitions for up instead of one—in cases where Y-up is more convenient, this leads to two rotations instead of zero. There's no significant efficiency cost either way, but it adds a layer to the math, which makes it easier to make mistakes. (Such as with Minecraft, which routinely and to my great displeasure switches handedness randomly during rendering.)

Anyway.

If we want to be really classy, we could be like POV-ray, and make the user specify right, up, and forward vectors, permitting any handedness and axis definition the user finds convenient. Just as long as we don't be like POV-ray in making left-handedness the default.

Further discussion of units and prefixes in SI vs. IEC prefixes and bytes, where it is less off-topic.

The most natural system (for me at least, but hopefully many agree) is: X forward, Y right, Z up.

I realize that "intuitive" is almost entirely subjective, but I'd like to know what I'm missing here because neither "x forward" nor "y right" seems in any way obvious or intuitive.