PHP: Расширенный текучий интерфейс

Ну, смотрите. Фишка в том, что не всякое можно мешать воедино.
Так или иначе у Вас должно быть разделение, чтобы не было хардкода, чтобы соответствовать объектной структуре Вашего приложения.

Дело в следующем:
Вы сказали, что подобный прием используется в Javascript библиотеках, таких, как, например, jQuery.
К слову, такое еще используется во всяких библиотеках, которые строят чарты вроде openflashchart.

И там, и там цепочки выстраиваются в рамках первого главного узлового объекта и заканчиваются сразу, как только мы исчерпали скоуп. Да, не смотря на то, что это не ORM, скоупы никто не отменял.

Важно понимать, что действия, которые Вы выполняете такими методами должны быть четко связаны с предыдущим элементом или его родителем. В противном случае Вы получаете обычное функциональное программирование, только не через точку с запятой, а через стрелочку.

Веду к тому, что архитектурно работу Вашего приложения нужно выстраивать следующим образом:

function APP(){return Application::Instance();}
// при создании экземпляра объекта приложения (синглтон), автоматически вызывается метод Init(), который отвечает за загрузку конфигов и первичную инициализацию переменных

App()->group=123; 
App()->student=431;

// к слову, две предыдущие строки - лишние. Если Вы хотите работать с $_REQUEST, имеет смысл загнать все параметры в свойства объекта Application автоматически на этапе инициализации, либо забросить их в массив и получать доступ к ним через волшебные методы, ну или воспользоваться кодом ниже:
/*
public function __get($name){
  return isset($_GET[$name]) ? $_GET[$name] : (isset($_POST[$name]) ? $_POST[$name] : null);
}
*/

// А теперь самое интересное:
APP()->addTree () // добавили в приложение дерево
  ->InitFromConfig () // проинициализировали дерево из конфига
  ->ActivateGroup (APP()->group) // сделали активным узел с группой
  ->ActivateStudent (APP()->student); // подсветили текущего пользователя

APP()->addContentField(APP::C_PERSONAL_PAGE) // добавили в приложение область контента с типом "персональная страница"
  ->AttachUserProfile( APP()->sudent ); // и отобразили профиль выбранного студента

Все дальнейшие действия точно так же атомарно бьются, а за атом принимается любая самостоятельная группа элементов интерфейса.

Ну а дальше — рендер, который в случае раздельной архитектуры должен идти отдельной прослойкой после того, как были выполнены все действия с данными.

APP()->Crumple()
  ->SetTemplate('template1')
  ->DisableCache()
  ->EnableGoogleAds()
  ->Render()
  ->Print();

Что касается запросов на изменение отдельно аватарки или выборочных полей в профиле студента, то здесь тоже все просто и красиво с теми же объектно-ориентированными цепочками команд.

// уровень обработки данных.
// грубый пример реализации функционала выборочного изменения частей профиля
if (APP()->ajax){
  switch (APP()->action){
    case 'changeAvatar':
      APP()->Students()->getById(APP()->studentId)
        ->setAvatar($_FILES['avatar'])
        ->Save();
        break;
    case 'changeAvatar':
      APP()->Students()->getById(APP()->studentId)
        ->setName(APP()->name) // все проверки и санация переменных внутри метода
        ->Save();
        break;
  }
  die(); // это был всего лишь ajax-запрос на изменение. Здесь перед самоликвидацией можно поставить вывод JSON-ответа о том, что все прошло хорошо.
}

Таким образом все получается аккуратно:
— отдельные аспекты описаны отдельно
— потоки команд применены для всех объектов
— можно четко отделить обработку данных от непосредственного вывода

Главное — не переусердствовать и видеть границу между «красиво» и «понятно и работает»

дело вкуса