Won't fix list

What follows is a list of features that are purposefully not implemented.
This list might grow, but I may be convinced to change my mind on some of them.

Clamp is incorrect, there should be Clamp and PartialClamp instead (Ord vs PartialOrd)

No, this would create an otherworldy mess for an issue nobody actually cares about! People clamp floats and ints all the time.
If we did this, we'd have to do it for too many traits. Just picture the impact on Wrap, Lerp and Slerp.

Factor and Progress types (for Lerp, etc) are real numbers, therefore they should have a bound on Float.

No, because it adds no value whatosever. Also, fixed-point numbers can't implement classify(), infinity(), etc.
This might be solved by someday, but it doesn't change the answer.

Iterating on matrices directly.

You want to iterate over the public member instead. Transpose the matrix if needed!

collect()-ing matrices directly.

Same as above; Collect the public member instead.

Indexing matrices directly, like m[i][j].

Write m[(i, j)] instead, which has the benefit of being layout-agnostic.

Matrix division.

I'd rather meaningfully multiply by the inverse. At least, inversion fails explicitly.

swap_* functions for matrices.

People can use mem::swap() on members directly, bypassing bounds checking.

invert_orthogonal() or invert_rotation().

It's better to explicitly call transpose() to invert a matrix that is known to be orthogonal.

Angular (Rad or Deg) newtypes.

They have no way to enforce correctness, and get quickly annoying to use.

Per vek's mantra (i.e stay true to reality), all angles are assumed to be in radians, because this is the unit that's actually used for calculations.

Also floating-point types already have to_radians() and to_degrees() in Rust. If you want to support degrees so bad, then I dunno, write your own wrappers or properly handle conversions yourself.

Indexing on Quaternions

You may convert the quaternion to Vec4 then index it.

Non-square matrices

They add too much implementation complexity for a way too weak return on investment.
Non-square matrices are too much of a pain to deal with when generating code via macros for what it's actually worth.

Personally I've never used them, but it seems that they allow sparing some memory.
If you're concerned about this, don't forget that you can simply store appropriate vectors of vectors (or even more compact structures) and convert them on-the-fly to vek's square matrices, as needed.
Y'know, SIMD multiply of 4x4-matrix by vector4 is most efficient!

In GLSL ES, there are only square matrix types (only the NV_non_square_matrices GLSL extension brings them back).
Even in desktop GL, non-square matrices are seldom used (See this StackOverflow question).