I suspect that some of the confusion stems from a lack of a shared set of goals and principles. Hence this message. I'm going to pretend that we are designing a new protocol, not changing an existing one, to avoid confusing the issue with debates about broken implementations or minimal changes. Until we can agree on what we want the protocol to do, it's pointless to argue over how it does it.
Correctness always takes precedence over performance.
If we can't agree on this one, then we will never reach consensus about a caching design. This is also a version of the robustness principle. This could be constructed from a timestamp, but only if the server is able to guarantee uniqueness of the timestamp. A server must have a way of deciding if the version string is valid for a given object, but the protocol specification need not concern itself with how this is done. If a server is unable to generate useful version strings, it can still conform to the spec but it must specify that the objects it returns are uncachable.