Ну а как это сделать не имея два независимых списка? Никак! Единственное что мне приходило в голову, это сделать механизм Payload'ов - добавить в адаптер метод, в который можно передавать только "изменения в списках". Т.е. вы в этом методе передаете только то что нужно поменять в текущем списке. Тогда список остается один. Но это накладывает кучу граничных случаев по типу синхронизации данных или неправильной генерации этих изменений. Поэтому я пошел по типу как предлагает гугл - новый список и правильный DiffCallback. В обоих случаях надо одинаковое время на просчет изменений. Но в случае с DiffUtil callback тратится в два раза больше памяти (старый список и новый список), но только на момент отрисовки. С учетом того, что во многих современных приложениях и так эти списки генерятся новые (запрос на сервер - как не крути, это новый список, к примеру), то смысла не вижу изобретать велосипед. Проблема с DiffUtil наблюдалась пока только на огромных списках у меня (10000+). Там этот механизм может жрать знатно как и времени так и памяти, но я не пробовал его скрещивать с Paging Library, думаю она и эту проблему решит.