Если в нашей дискуссии есть практический смысл (реализация Etag в ближайших версия).
Я могу много рассказать про невозможность использовать Last-Modified для ревалидации.

Реальный пример из жизни, у нас есть страница товара, ниже выводим комментарии пользователей, хедер страницы Last-Modified – это дата создания/редактирования товара, это необходимо для поисковиков RSS клиентов и т.д. При добавления нового комментария мы не можешь изменить Last-Modified всей страницы, мы можем изменить только её ETag, и самая большая проблема Last-Modified это точность до секунды, к сожаления два комментария могут прийти в одну секунду, но в кеше появится только первый комментарий, второй комментарий просто не сможет сбросить кеш потому что у него такой же Last-Modified.

Но главная особенность, Etag он может хранить серелизованые значения или хеши которые являются ключами в NoSQL, в них хранится расширенная мета информацию для использования её в бекенде при ревалидации, с Last-Modified этого сделать невозможно.

Etag не просто удобней использовать, он даёт новые возможности которые не может дать Last-Modified, по этому поддержка Etag это стратегический вопрос а не тактический.

Не понимаю зачем менять версию кеш файла, для передачи Etag в бекенд?
Нам для полного счастья нужна одна мелочь HTTP_IF_NONE_MATCH, серверу нужно её заполнить значениям из файла кеша и передать на бекенд, все больше сервер ничего делать не должен, бекенд ответит статусом 304 или 200.
Зачем ждать светлого будущего, если можно создать светлое настоящие для Nginx уже сегодня, осталось мелочь реализовать Etag в ревалидации