2. Это элементарно: многие продолжают сидеть на XP. И на то есть масса причин, хотя бы банальное удобство в отношении тайлсетов! А если ты переопределяешь методы Graphics, то сложности с исполнением явно не возникнет. Если же какой-то метод будет очень плотно завязан на использование библиотеки конкретного мукера и ее использование в другом будет невозможно - что ж, этот сопрный момент мы решим.
3. Совершенно верно
4. Согласен, как с рекомендацией - по желанию авторов. Желающие также смогут дописывать эти комменты сами.
5. В RGSS ее нет - прекрасно. В пользовательских скриптах она порой встречается, притом в особо извращенной форме, вроде: m_name, m_year, помимо обычных iIndex
6.
а) Какие имена должны быть у констант из нескольких слов? "COUNTOFTILESINTILESET"?
CountOfTilesInTileSet, например?
б) Скачущий стиль будет гораздо хуже. Потому что все, или почти все, сторонние скрипты написаны с оглядкой на стандартные и в его стиле. Не нужно плодить сущности без острой на то необходимости.

Вообще, предлагаю не трогать стиль оформления кода RGSS. Самому-то приятно будет читать код, где в одном месте ($gameTemp.shopGoods и LETTERTABLE), а в другом ($game_temp.shop_goods и LETTER_TABLE)? Зачем путать людей? К чему эти эстетские замашки? Как будет осуществляться совместимость с другими скриптами?
А кто-то говорил про совместимость? Мое мнение - если уж займемся плагиатом (а мы им займемся), то чужие творения также придется переписывать, подгоняя под наши реалии.
Но насчет сущностей, пожалуй, соглашусь. Действительно определенный стиль уже укоренился, что не может не огорчать... (кстати, ты не привел в пример attr_* )

Наконец 1:
Откуда такие пораженческие настрои? Сейчас повыложим сверхклассы, поправим то, да сё, потом кто-нибудь захочет переделать Scene_Title и понеслась...
Загнуться может проект, идущий к невыполнимой / неподъемной цели. Абстрактная же ни к чему не обязывает, и не заставляет торопиться с ее выполнением. Получится в итоге новая система скриптов, которую можно вставить хоть в XP, хоть в VX? Прекрасно! Нет - будет набор методов для определенных классов, которые кому-нибудь пригодятся в проектах. Только и всего.

Касательно второй части - замечательная структура для подачи заявок на изменение тех или иных методов/классов. Согласен, надо бы под это дело завести отдельную темку (займешься? ). Но только не как обязательное требование перед выполнением чего-либо. Будет очень много полемики и очень мало действий. Если человек что-то пишет без согласования с другими. он должен понимать, что с этим могут не согласиться и его усилия пропадут в Туне. Если он пишет несмотря на это - его право.

Поднял замечательные вопросы. Давай дальше в том же духе.