Please consider changing the quaternion element storage order back to x, y, z, w, as it was before version 0.9.9.6, before the change due to issue #916.

The change of the internal element order is a breaking change for many users of the glm quaternion library. A necessary feature of a useful low-level, high-performance library like glm is binary backward compatibility, and this is completely broken with this change.

I have no doubt that many users of glm quaternions have yet to pull the latest version and rebuild their projects. They will be surprised and once they figure out what happened, they will most likely (like me) revert to 0.9.9.5 and never upgrade again. I know that with a version 0, binary compatibility should not be relied upon, but I am sure I am not alone in expecting this basic element order to stay the same as it has been for many years.

I understand the reasoning for changing the order, per issue #916, but I have to say, this is a c/c++ library; the constructor element order is a very minor detail, easily worked around if you don't like it, while the underlying storage order is not.

By the way, I appreciate this library very much, and want to thank everyone who has helped make it great! I just want to add my perspective since I am sure this quat change will cause problems for many users of the library besides me.

A few arguments for changing the order back to x, y, z, w.

• Backward compatibility. There are many cases where quaternions are copied to disk (storage, retrieval), copied to pinned gpu memory for use in shaders, etc. Element-wise access for this type of use is a performance hit in many cases, not to mention convenience.
• Consistency. glm::vec4 is stored x, y, z, w, as are glsl vec4. I can name many libraries that store quaternions in this order. For example: Eigen.

Please consider this a humble petition to change the order back to x, y, z, w, and I would invite everyone who sees this to add to the arguments, or present counter-arguments.