Как строить асинхронное приложение?
В общем это dataflow граф, где узлы срабатывают, когда по всем входящим дугам пришли данные (как в (раскрашенных) сетях Петри). С этой точки зрения callback — это дуга, переданная в сообщении и в которую надо отправить ответ. 

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

Для actionscript готовых решений не знаю, знаю только для java — df4j (сам написал, очень простая).

en.wikipedia.org/wiki/Flow-based_programming

Модель_акторов:
ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%BE%D0%B2
Может есть смысл завести массив запрашиваемых наборов данных и заполнять их по мере приема, а из кусков интерфейса периодически проверять, не появились ли данные для текущего представления?
Что-то вроде массива или структуры:
struct my_data {
  bool received;
  uint32 request_time;
  uint32 receive_time;
  uint8 *buff;
  data_struct unpacked_data;
  ...
};

struct my_data_storage {
  struct my_data *main_data;
  struct my_data *section1_data;
  struct my_data *section2_data;
  ...
};

Соответственно при открытии любого интерфейсного блока(section) он запрашивает свои данные у… назовем это «контроллер коммуникации» — поток или объект, отвечающий за работу с удаленными серверами. Далее интерфейсный блок ждет, периодически проверяя готовность данных и отображая что там вы отображаете(крутящееся колесо или пустую табличку или еще что).

Можно контролировать таймауты приема, устаревание данных и т.п., поля request_time и receive_time у структуры блока данных в помощь.

Пример алгоритма:
 — Пользователь открывает в интерфейсе блок section1.
 — Показываем этот кусок интерфейса пустым или с крутящимся колесом.
 — Смотрим в хранилище данных данных на поле section1_data. 
 —  — Если оно NULL, интерфейс шлет запрос данных контроллеру коммуникации, тот в свою очередь шлет запрос данных к серверу, создавая и инициализируя начальными значениями в этом поле структуру my_data.
 —  — Если оно не NULL, смотрим на поле received(данные приняты и распарсены полностью). Если данные еще не приняты, ждем дальше. Если данные приняты, смотрим по receive_time их актуальность, если еще актуальны(таймаут устаревания не прошел), то отображаем, если нет — перезапрашиваем еще раз(при этом поле section1_data обнуляется и пересоздается заново, либо просто переинициализируется).
Контроллер коммуникации например может сам контролировать таймаут приема данных и выставлять флаг неудачного запроса.
Ну и т.п.
Многое зависит от того, на чем вы пишете, под какую систему, от реализации интерфейса и т.п. Как это все вместе соединить, вам решать под себя.

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