What problem does this solve or what need does it fill?

Currently the camera keeps track of the near and far values. These values are not only not used but in many cases cause confusion as there can be projection matrices where a particular near or far value doesn't make sense. One example is the currently used reverse infinite perspective projection matrix which has no far plane.

Additionally since these values correspond to properties of the projection matrix it's expected that they are always in sync. This introduces points of failure if these values are not handled correctly.

What solution would you like?

I propose that we should remove these values from the camera (and views) since they to my knowledge they are never used. The only exception is the ClusterFarZMode::CameraFarPlane which just simply uses the camera's far field. Since the camera's far value is already just an arbitrary number we could just as well use the ClusterFarZMode::Constant.

What alternative(s) have you considered?

Since the main confusion is caused by having both a projection matrix and it's internal properties in the same component another solution could be merging the projections and the camera and having the camera compute it's projection matrix. This solution would simplify the use of camera but would make arbitrary projection matrices practically impossible.

Additional context

If there is a reason why the near and far values are tied to the camera and not only to the specific projections please let me know and maybe I can document it in the future.