2.1. Нет списка со значениями, не являющимися объектами. Например, целыми - Int.

2.2. Списки не очень удобно реализованы. Было бы хорошо наличие у элементов списка TLink поля Parent, для ссылки на родительский список (И поля Child для многоуровневых древовидных списков). Это связано с менеджером памяти языка, который не в состоянии корректно удалять объекты с кросслинками.

2.3. Утечка памяти в функции LoadImage при загрузке *.png. Ее практически не заметно, т.к. вылазит она при особых случаях, например при перегрузке картинок, что обычно не требуется - они загружаются один раз обычно. Но, например, при отсутствии менеджера ресурсов, когда нам нужно перезагружать изображение (при обработке скриптов, например), то утечка становится заметной. Причем внутренний меденжер памяти утечку не показывает.
Прим.: при загрузке *.jpg утечки нет.

2.4. При создании нового pixmap, он не инициализируется. Т.е. мы создали новый pixmap, а там мешанина из пикселов, а не черный или белый или заданный программистом фон. Надо писать функции заполнения новообразованных пиксмапов, а это - время/деньги. Исправлено в последних версиях. С 1.24 появился метод у класса ClearPixels( argb ) и функция ClearPixels( pixmap:TPixmap, argb=0 ), которые и проделывают эту работу /спс за поправку SBJoker/

2.5. Неясности со шрифтами: LoadImageFont("Arial.ttf"…) не приводит к ожидаемому результату, а с полным путем LoadImageFont("C:\Windows\Fonts\Arial.ttf"…) все работает. Хотелось бы без указания путей. Хоть и есть фонт по умолчанию.

2.6. Отсутствие такого хорошего понятия как контекст устройства. Есть в вынь и в пурике ( StartDrawing(OutputID) ). На CreateGraphics(…) его заменить нельзя - если разрешение не поддерживается, контекст не создается. Это очень-очень плохо. Нельзя рисовать нормально в оффскрин окно. Другими словами рисовать в текстуру (спрайт) можно только ручками через массив пикселей, что медленно. Сторонние библиотеки для этого - платные.
Upd:Также можно рисовать и не ручками, а хардварно. И библиотеки уже есть даже бесплатные для этого. Только все кривые.

2.7. Метод pixmap. Paste(…) не проверяет размеры - это приводит к глюкам с затиранием памяти и необходимостью писать много чего своими ручками. Это unsafe (при том, что полезные вещи в страхе этого самого unsafe не делаются), и время/деньги на дополнительный код.

2.8. Глючность идиотическая, надеялся, что такого не встречу. Пример: когда работа с пиксмапами формата PF_RGBA8888 проходит отлично, а смена формата на PF_BGRA8888 приводит к непонятным глюкам в официальных библиотечных функциях.

2.9. Глюки при работе с созданием пиксмапов, если их делаешь много, то возникает глюк. Этот глюк как-то связан с форматом картинки. При формате PF_BGRA8888 он возникает раньше. GCCollect() не помогает, дело не в переполнении, а хз в чем.

2.10. Звук: Полная распаковка/загрузка в память, потом проигрывание. Это приводит к тому, что мы в программе уже запустили звук на проигрывание, а оно начинается позже - после полной распаковки. Это заметно даже на не сильно больших звуках, не треках. Сначала было совсем жестко - распаковка была не в отдельном процессе и можно было нарваться на притормаживания при попытках проиграть звук. Потомсделали распаковку в фоне (отдельным процессом). Этим убрались притормаживания всего приложения при проигрывании. Но остались паузы между желаемым началом проигрывания (вызовом в коде) и реальным началом, когда уже слышен звук.
При этом, фоновая распаковка породила другую проблему. Тормоза при не фоновой распаковке можно было обойти правильной организацией ресурсов. Загрузкой и распаковкой звуков в начале игры или уровня, когда можно и подождать. Таким образом, при самой игре звуки проигрывались уже распакованные из памяти, не вызывая никаких нареканий. Теперь при такой организации, если приложение загрузилось достаточно быстро, а звуки в фоне не распаковались, то опять есть паузы в начале работы, между тем, когда звук должен проиграться и когда он звучит на самом деле. Вылез теперь немного иной недостаток - невозможность узнать, когда звук распакован, чтобы дождаться полной загрузки ресурсов.
Правильнее бы делать блочную распаковку/загрузку и проигрывание. Как в винампе, например. Когда подгружается кусок и распаковывается быстро и играется сразу, незаметно для слуха. А потом в фоне догружаются остальные части.

2.11. Нет форматирования текста. Для вывода например дробного числа с 3-мя знаками после запятой и т.п. Нужно для нормального отображения информации, чтобы строки не налезали друг на друга. Можно сказать, что для игр и не важно, но а вывод вспомогательной дебаг информации?- очень даже нужно.

2.12. Нет математических функций для округления чисел с плавающей запятой до нужного количества знаков после запятой. Почти, то-же что и п.2.11, но с математической точки зрения. Но нужно было для того-же (вывод плавающих чисел).

2.13. Не обновляется содержимое окна при таскании его за заголовок (с тем-же фреймвоком от Поп-Кап таких проблем нет).

2.14. Нет команд для временной передачи лишнего времени системе. В Win и PalmOS это вполне возможно, в других ОС, думаю, тоже. Такая команда найдена! И называется она PollSystem. Кстати в тему: команда Delay тоже не отъедает все время системы. По крайней мере в Виндовс, т.к. вызывает АПИ-шную Sleep, которая просто "замораживает" выполнение треда на указанное время. Так-что на PollSystem и Delay вполне можно огранизовать нересурсоемкую задержку для синхронизации по времени.

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

2.15. Неточности при определении столкновений.