Иван

Вы путаете параметры роутера с параметрами query string ($_GET), которые вообще в роутинге не указываются и могут быть любыми или вообще отсутствовать. В данном конкретном случае id в роуте не нужен. А параметры lines и pages надо извлекать из запроса через $this->request->query(), как-то так:

$data = array(
        'lines'    => (int)$this->request->query('lines') ?: 10,
        'pages'  => max(1, (int)$this->request->query('pages')),
    );

Хотя я бы использовал более общепринятые параметры типа offset/limit или page/perpage. Более понятные названия, имхо.

Обратите внимание, что весь функционал модели Model_User на самом деле расположен в Model_Auth_User, а в Model_User только наследование. Скопируйте Model_User в application и там добавляйте нужные связи, методы и тд. Одно НО - если Вы добавляете свойство $_has_many в Model_User, то оно перезатрет родительское. Выходов два:

1. Скопировать свойства из Model_Auth_User и добавить еще свое. Это особенность Каскадной Файловой Системы Kohana, почитать можно в официальной доке или тут (или еще где-то в интернете, на русском про основы Коханы уже все давно разжевано).
2. Свойства можно добавлять динамически, посмотрите на метод _initialize(), который вызывается для любой модели ORM. В Вашем случае будет что-то вроде:

protected function _initialize()
{
    // сперва пусть отработают родители
    parent::_initialize();
    $this->_has_many['types'] = array('model' => 'Type','through' => 'types_users');
}

1. Возвращаете обратно экшен, в котором проходила валидация и сохранение комментария (с перезагрузкой страницы). В нем будет проверка как данных собственно комментария, так и капчи.
2. Добавляете проверку на is_ajax(), в зависимости от результата отдаете редирект или HTML-код вьюшки (для не-аякс запросов), либо JSON или еще что-то (можно смотреть на заголовки, можно не париться и отдавать всегда json). В json'е будет результат операции ('result' => true, к примеру) и список ошибок валидации ('errors' => {'field' : 'error', ...}. Если сохранение успешно, то отдавать id комментария или еще что-то, смотря что планируете делать в случае успеха.
3. При сабмите формы отправляете ajax-запрос с данными (+капча). Если есть ошибки (смотрим на result, на errors и тд), то выводим их на форму.

Соответственно, у пользователей с отключенным js добавление комментариев работает с перезагрузкой страницы, а для остальных есть ajax. При этом экшен один на всех.

В любом случае, никогда не полагайтесь только на ClientSide-валидацию. На ServerSide (то есть в пхп) в любом случае все эти проверки делать надо будет.

А тупо сессии проверить? Ибо это больше на сессии похоже, чем на куки. Закиньте одному пользователю в сессию что-нить, появится у второго? Ну или поменяйте драйвер сессии.

Могу предложить добавить вызов обработчика в файл index.php, сразу после Request::factory()->..;
Как раз то, что нужно — контроллер отработал, фреймворк еще не закрылся.

Штатные библиотеки Kohana пробовали? Тот же OAuth должен работать.

1. Почему проверка имени через $external_validation? Что мешает просто добавить правило (как в Auth сделано)?
2. Вообще, лично для меня вторая модель (User_Contacts) не является обязательной. Соответственно вижу два варианта:

* сохраняем первую модель и просим пользователя отредактировать контакты. Даже если он их не сохранит, они опциональны (ну или будем настойчиво их спрашивать, если все же нужны)
* сохраняем первую модель + те поля, которые прошли валидацию. Все, что не прошло из-за ошибок, показываем пользователю. Мне такой вариант нравится больше.

В общем, не паримся с транзакциями, а однозначно зависим только от правильности первой модели (она основная у нас).

Честно говоря, скептически отношусь к этому циклу… Он ориентирован на самых начинающих (или тех, кому лень почитать официальный мануал или wiki). Как по мне, был бы полезнее материал типа «Kohana 101», если помните такой. Т.е. один документ, описывающий основные моменты при работе с Kohana (каскадная файловая система и модули, модель MVC, автозагрузка и т.д.)