Did you know that quaternions were found before vectors?
Yes
needs (...) Z-buffering, image-order
PowerVR GPUs don't need these.
Now, one can argue that some textures are prone to aliasing (say a normal map) because you can't filter them easily. But, hopefully, your accesses aren't too chaotic or else you can experience aliasing even if you implement your own custom filtering and performance is likely to suffer as well.
Virtual texturing allows you to do efficient texture space lighting (and processing). You will sample the linear space rgb values = filtering is possible.
Whatever the fixed storage format, it can be defeated by image-based reads. It won't be as fast as traversing headlong (and going to slow RAM only once per n > 1 accesses) & splatting a (say) Morton quadtree. In this respect the MIP pyramid is, again, maliciously ill-formated: the levels aren't in Morton order (or any such Peano style sequence). It just is unbelievable.
If you do texture space lighting (with virtual texturing) you will access all your material textures in a linear order (processing every single bit of every cache line). Only the resulting value (that is a small fraction of all your material textures in both BW and storage) needs to be sampled. As your texture sampling pass will be a full screen compute shader pass, and you will use Hilbert curve ordering (best locality) for your compute threads, the memory locality will be actually very good. I suggest that you implement a compute shader that colors the cache lines in screen space. This way you will notice that the locality is actually very good, and very high percentage of each loaded cache line is accessed. GPU can hide the latency of the misses quite well (90%+ execution unit utilization is achievable with proper tools and optimization effort).
What an abomination those floats: they each carry their exponent, what a waste of space (and of time).
Storing useless data is useless. If your data is in any structure that makes it easy to determine the high bits (or the exponent), then there is no reason to store them. However there is no self balancing structure of this kind that supports O(1) modification of values. So it is always a trade off (faster static world vs faster dynamic world).
C++ is so falsely abstract it's not even funny. Your mind should be dealing with abstract beings, not your hands: abstract things aren't in space-time, their size here is 0. With C++ one pretends to be abstract while writing endless (not of size 0 in space-time) empty (of size 0 there) words. C is ad hoc, concrete. A C user thinks much and writes little.
C++ is almost as concrete as C. Try programming some Haskell or any other modern functional language and you will notice a real difference.
Donald Meagher was sabotaged, it is obvious that his renderers should have been preferred.
Many graphics programmers would like to have completely different hardware to suit their own needs (I do at least). The best can adapt to the hardware that is available. Modern GPUs are quite programmable indeed. For example in your renderer, we use the rasterization pipeline only to fill the depth buffer + another buffer (we don't even sample any textures in the rasterization pipeline). Most of the processing (including all texturing) is done by the compute pipeline, by our own algorithms.
No matter the format, accessing it by way of the pixels' detour won't be neighborly in general (observing a wall at a sufficient angle will result in the next pixel's tex. sample to be rather far from the current one).
If you want, you can do texture space lighting (= material sampling) on any modern GPU. Virtual texturing helps. But then again, sparse quadtrees (containing wrapped surface material and displacement data) are quite similar to sparse octrees (containing volume data).