Появилась забавная, но интересная идея. Раз уж wiki-разметка используется в блогах, то почему бы не пойти дальше? Почему бы не разрешить посетителю по двойному клику на записи в блоге что-то изменить или добавить?

В дополнение к «обычным» (стандартным) функциям «обычного» блога хочется вот каких полезных вещей:

• Записи без даты (ex: [ >>> ] , [ >>> ] )
  
• записи «задним числом» (т.е. возможность выставить нужную дату)
  
• интеграция с rss-агрегатором (свой или 3rd party)
  
• поддержка нитей ( [ >>> ] ) — записей последовательного характера с хронологией развития событий (удобно смотреть развитие идеи/ситуации в динамике или описывать стадии проектирования: идея — разработки — анализ — реализация)
  
• memories (избранное своих записей, не своих записей)
  
• масштабируемые keywords (ex: [ >>> ] захват не только ’register’, но и ’register fiction’; обратно — не работает) — когда область одного ключевого слова может включать в себя и другие КС: нет надобности в древовидных КС
  
• Фасеты (псевдофасеты/группы) — могут указываться прямо в теме: [life] ляляля, [work] блабла
  
• «быстрый архив» по заголовкам (ex: [ >>> ] ) с возможностью переключения на «полный архив» с полным текстом записей
  
• utx intergation: для тех, кто синхронизирует блог с LJ
  

Определяемые пользователем (для продвинутых пользователей, через api блога):

• user-defined tags
  
• user-defined link name rules (т.е. формирование линка записи: буквами, цифрами или еще как)
  
• wiki/html mode switch
  

В дополнение к wish-листу можно учесть еще вот это.
Писалось тогда это в шутку, но, как известно, в каждой шутке есть доля шутки. Остальное — это плод воображения гениального полета мысли. (два с половиной смайлика)

Второй (достаточно важный) момент связан с адаптацией под нужды и чаяния пользователя блога. Т.е. не банальная настройка дизайна и галочек в конфигурации, а возможность гибко управлять функциональностью движка. Но! Понятно, что одному пользователю захочется одно, а другому — другое. На всех не напасешься, да и нет смысла раздувать движок и список настроек к нему… проще дать пользователю механизм создания и подключения user-defined functions, возможно в виде callback.

Админ интерфейса, как такового, не будет, за одним исключением — страница добавления новой записи [ >>> ]
В e2 нет такого понятия, как «админский интерфейс» [ >>> ]

Что касается InTerra, то добавление новой записи можно организовать прямо в основной ленте…
Но все равно интересно — а почему отсутствие админки — это величайшее достижение блогостроения?

Кстати, об админском интерфейсе. Его действительно можно не делать, но он, тем не менее, будет. Если использовать user-defined interface.
Мысль проста: если у нас есть скрипт admin.php, обрабатывающий get/post запросы, то формочки к нему можно хранить в [обычных] блоговских записях («записи без даты»). Т.е. при помощи стандартных механизмов работы с записями мы можем построить «виртуальную админку».
Плюс: 100% interface customisation
Минус: нет оптимального механизма «обратной связи» — передачи переменных в формочку

Пример: формочка для поиска у меня хранится в обычной записи. И при редактировании она выглядит так.

В дополнение к «Связи данных» надо сказать, что многие вещи в readme не реализованы по причине того, что я чаще всего занимаюсь небольшими, но нетрадиционными вещами. А прикладные проекты мне тянуть трудно. Вы будете смеяться, но я не знаю php… хотя скрипты на нем пишу.
Идей, однако, хватает. Желающие могут прошерстить readme — по классификации записей и блогостроению я много чего писал. И еще напишу — например, о record embeding.

Уважая бритву Оккама, надо сразу сказать, что СК должны взаимно дополнять друг друга, а не дублировать. Это не обязательно, но желательно. Надо быть реалистами и верить в три зеленых свистка.

Так вот, о нитях (threads)и связывании записей можно сказать, что КС и нити не зависимы друг от друга (разнесены по плоскостям в идеальном случае), хотя и пересекаются. Это, кстати, удобно — записи одной нити могут иметь разные КС и, соответственно, разные спектры группировки на кучки.
Технологически поддержка threads разбивается на два этапа:
а) вставка записи в нить; производится аналогично КС (но плоскость имен не пересекается)
б) визуализация нити; вот тут можно извращаться различными методами: графически, на флеше с zoom, линками next/prev или методами «etc». На свой вкус.
Только не надо пытаться смешать в один клубок КС и thread — сами же и запутатесь.