Не вижу зачем или для чего нужно менять статус?

Спору нет. Я говорил не о ВАП, а об окнах в ВАП.

Я думаю не стоит мешать в одну кучу выделение/освобождение физических страниц и настройки виртуального адресного пространства. Это 2 независимых уровня.

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

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

И кроме обычного выделения - запрос разделяемой памяти. Обычно в Unix-like операционках для этих нужд используется (реализуется) системный вызов mmap(). Выделение разделяемой памяти может быть обычным. Т.е. ядро выделяет любую доступную память и делает ее доступной процессу. Или ядро выделяет конкретный диапозон физической памяти и делает ее доступной процессу (возможно нескольким процессам). Такой механизм необходим для написания драйверов устройств.

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

Если есть предлагайте.
На данный момент провожу мозговой штурм. Который должен ответить на вопрос, а что же надо? Знал бы где упадёшь соломки бы подстелил. А на данный момент мне трудно угадать. А схемы диаграммы статьи и прочая документация у меня ведётся. Просто публиковать буду по мере готовности.

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

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

Отображение ядра, хранящегося в базовой памяти, в верхнюю часть ВАП (тем более в виде большой страницы) тоже не делаю. Максимум могу отобразить в пространство ядра первую физ. страницу (4 кб) ради экономии.

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

Таблица страниц, включая каталог, также традиционно относится к пространству ядра, хотя в ней естественно есть и "локальные" страницы.

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

Для примера мой вариант разметки прикладного пространства:
1) stop frame (guard page(s));
2) секция кода;
3) секция данных;
4) секция bss - изначально не выравнивается на границу страницы;
5) секция rma (предназначена для резервирования участка ВАП) - изначально не выравнивается на границу страницы;
6) свободное пространство - здесь может быть размещен след. модуль;
7) здесь могут быть размещены стеки доп. потоков;
8) стековый stop frame (guard page(s));
9) стековый резерв;
10) стек.
В принципе начальный состав секций отдельно взятого модуля может меняться, но в данный момент я использую такой формат исполняемых файлов, при котором это невозможно.