История изменений

Нет, это задача не Xorg, а прокси-уровня (коим в некотором роде и тулкит тоже является). Тут вообще нигде не говорится про то, чтобы этому научить именно Xorg. Он сделан так, как сделан - уже ничего не попишешь. Но вот возлагать эту работу на тулкит - это просто решение для конкретного тулкита. И такое решение было еще до GTK (например, XTk). Более того, приложение может быть вообще без тулкита, а сохранять надо.

чтобы добиться того же эффекта, придётся сохранять всю историю общения клиента с сервером, что весьма непрактично.

Это не так много информации, на самом деле. А ты думаешь, что в GTK хранить пиксмап дополнительно не придется? Если тулкит гоняет картинками, которые отрендерились на стороне клиента, то все само собой решается, так как тулкиту не надо ничего из сервера выгружать, у него исходник. А изначальная концепция приложений X11 предполагала, что ты пиксмап грузишь на сервер, а потом оперируешь XID, рисуешь что-то на нем, композитишь, а само приложение у себя копию этого пиксмапа не хранит. И если сервер теряет pixmap или picture (в Render), то его надо где-то приложению взять, а ты на сервере уже туда градиентов нарисовал, кругов. И как выглядит теперь этот пиксмап знает только сервер. Если он его потеряет, то все. Тулкиты, которые работают именно по такой схеме, уже никак не восстановятся. Им только придется реализовывать отрисовку на своей стороне или придумывать сложные схемы, как это заново все рисовать (если такое вообще возможно).

https://demonastery.org/2011/04/change-gtk-display-on-the-fly/

А вот это еще надо выяснить, каков механизм. Потому что одно дело, когда клиент может выгрузить из сервера то, что ему нужно (пиксмап можно выгрузить, а остальные ресурсы пересоздать потом), но возникает вопрос, как это будет себя вести, если сервер упал внезапно? Будет ли это приложение persistent? То есть переход на другой дисплей возможен только пока это приложение живо или даже если сервер внезапно пропал? Пока мне кажется, что речь идет именно об управляемом переходе на другой дисплей при живых X-серверах. Может быть, я неправ, так как я не успел выяснить, как это реализовано.

Нет, это задача не Xorg, а прокси-уровня (коим в некотором роде и тулкит тоже является). Тут вообще нигде не говорится про то, чтобы этому научить именно Xorg. Он сделан так, как сделан - уже ничего не попишешь. Но вот возлагать эту работу на тулкит - это просто решение для конкретного тулкита. И такое решение было еще до GTK (например, XTk). Более того, приложение может быть вообще без тулкита, а сохранять надо.

чтобы добиться того же эффекта, придётся сохранять всю историю общения клиента с сервером, что весьма непрактично.

Это не так много информации, на самом деле. А ты думаешь, что в GTK хранить пиксмап дополнительно не придется? Если тулкит гоняет картинками, которые отрендерились на стороне клиента, то все само собой решается, так как тулкиту не надо ничего из сервера выгружать, у него исходник. А изначальная концепция приложений X11 предполагала, что ты пиксмап грузишь на сервер, а потом оперируешь XID, рисуешь что-то на нем, композитишь, а само приложение у себя копию этого пиксмапа не хранит. И если сервер теряет pixmap или picture (в Render), то его надо где-то приложению взять, а ты на сервере уже туда градиентов нарисовал, кругов. И как выглядит теперь этот пиксмап знает только сервер. Если он его потеряет, то все. Тулкиты, которые работают именно по такой схеме, уже никак не восстановятся. Им только придется реализовывать отрисовку на своей стороне.

https://demonastery.org/2011/04/change-gtk-display-on-the-fly/

А вот это еще надо выяснить, каков механизм. Потому что одно дело, когда клиент может выгрузить из сервера то, что ему нужно (пиксмап можно выгрузить, а остальные ресурсы пересоздать потом), но возникает вопрос, как это будет себя вести, если сервер упал внезапно? Будет ли это приложение persistent? То есть переход на другой дисплей возможен только пока это приложение живо или даже если сервер внезапно пропал? Пока мне кажется, что речь идет именно об управляемом переходе на другой дисплей при живых X-серверах. Может быть, я неправ, так как я не успел выяснить, как это реализовано.