estic

В CMS (в смысле в панелях управления содержимым, в административных панелях) сейчас многое делается "на фронте". В головной части тоже, если нет цели придерживаться какой-то совместимости. Можно даже двойственное поведение реализовать для поддержания совместимости.

Это уже далеко не "с нуля". Использование "независимых" библиотек очень похоже на использование библиотек, входящих в состав какого-либо фреймворка. Программисты "с нуля" не пишут, не считая случаев написания нового функционала приложений (основная часть работы, но фреймворки при этом используются вовсю) и "изобретения" новых фреймворков (или их отдельных компонентов).

Конечно, мы все примерно понимаем, о чем вы пишете, но все-таки вы слишком вольно используете термины.

CMS создаются с использованием фреймворков. Фреймворки бывают "самописные".

Самоподписанного достаточно. Но лучше подобные панели не отображать во вне, т.е. разместить на локальном интерфейсе (loopback, etc.). Для доступа соответственно использовать SSH-туннель или VPN.

Не суть. Можно и так, если это проще реализовать. Хотя я писал о специальных "категориях", так что можно и так: /category/krasnye-sloniki. А если магазин поддерживает теги, то и никакие специальные "категории" не нужно выдумывать: /tag/krasnye-sloniki. Причем вовсе не обязательно использовать типичную теговую реализацию для таких случаев. Можно опять-таки внедрить в теги обычный фильтр для получения части результатов.

В общем же отдельные результаты фильтрации можно открывать для индексации, что по моим критериям позволяет использовать просто /krasnye-sloniki 😉

Ничто этому не мешает. Я писал о специальных "категориях", которые совпадают лишь с некоторыми результатами фильтрации. По сути это такие же результаты обычного фильтра, только немного "причесанные" (с простыми адресами, заголовками страниц и т.п.). Результаты, не имеющие специальных "категорий", будут выводиться в обычном виде (с более сложными адресами, заголовками страниц и т.п.).

Думаю, пользователь будет чувствовать себя увереннее, работая со ссылкой с адресом /krasnye-sloniki вместо /filter/page?category=slon&color=red и т.п. 😉

Чтобы адрес для сохранения (в закладках, внешних ссылках и т.п.) был более простой и понятный, когда фильтрация выполняется через обычный фильтр.

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

Обычный диалог (всплывающий блок или отдельная страница), который появляется при отправке (данных) формы.

Капча включается только при необходимости (при "атаках"). Выбирается такая (или такие), которая лучше всего противостоит текущим атакам. Не можете сами написать, используйте "готовую".

Главное, использовать диалог подтверждения. С ним, вполне вероятно, о капче долго вспоминать не придется. Кстати, реализация диалога подтверждения тоже может видоизменяться/выбираться.

Разбивку делаем. Но можно совмещать разбивку с "дозагрузкой" на бесконечную ленту (и при этом даже не менять адрес на JS).

Зависит от ресурса. Там где эксперты обычно "строчат" внушительные комментарии, можно и по 5-10 (на первой странице может быть даже 4-9 и т.п.). Иначе 10-20.

Так "дозагрузка" (AJAX). Причем часто ленивая (при прокрутке).

Какие дубли? Имеете в виду дублирование основного материала на дополнительных страницах? Я так никогда не делаю: комментарии похожи на сообщения форума без дублирования первого сообщения на каждой странице. Дополнительные страницы индексируются наравне с основной. Малополезные комментарии просто удаляем/объединяем/загоняем под спойлер, либо вовсе не допускаем к публикации.