> 1 Ответ на get запрос и даже сообщение от сервера вида "часть
> страницы изменилась", это как ajax, но без js. Пусть шлёт диффы.

1. Ресурсоемко.
2. Как это делать структурировано? Условно, JS может утянуть температуру, давление и влажность и получить с сервака, грубо говоря, 3 числа, которые вписать в поля морды проапдейтив значения. Само по себе это может быть дешево по ресурсам и на сервере и на клиенте если делать не через зад.
3. Браузер очевидно должен это уметь.
4. По каким критериям это случается? Сервак должен сам по своей инициативе пушить инфо в клиента что у него новая дельта есть? В случае JS и XHR или вебсокета там код так то может запросить данные когда это удобно по произвольному критерию, вообще любому.

Вопрос: как это все с диффами должно выглядеть? Сервак должен обсчитать вообще всю страницу с ноля, убив на это полный комплект ресурсов, потом еще дифф с этого сделать, и потом еще сверху этого - на обсчет дельты? И насколько это все редко-часто? Адаптив для разных задач? Показу погоды, чату и вебвьюхе ремотдесктопа нужны немного разные параметры IO.

> 2 Отправка и запрос документа не сначала до конца, а теми частями
> которые нужны клиенту.

Как бы клиенту нужно то что он попросил. Это ему и наливают. А более гранулярно - надо уже информировать и клиент и сервер об всем этом. Кто и где этим будет заниматься?

> и получим нечто асинхронное и возможно куда более быстрое. Это можно
> сделать оставив протокол простым и концептуально тем же http?

При сильном желании по HTTP гоняют даже некий диалект rsync, но все же не для браузинга.

> 3 include для html файлов
> 4 Экранирования на уровне документа. Можно будет разрешить всем html разметку, а
> на сервере даже не экранировать.
> 5 Загрузка папок (директорий).

Оно, видите ли, ушло в сторону когда "2 программы перекидываются данными". Морда-фронтэнд с сервером-бэкэндом. Это гибко и может что угодно, без дурацких ограничений на ровном месте. Хоть и обладает своими проблемами.