Сделать на основе Б24 не просто набор сервисов, а гибкую платформу для разработки в облаке.
Чтобы можно было конструировать свои произвольные объекты и писать для них обработчики.
Например, как реализовано тут:
https://bpium.ru/

Когда загружаешь последнюю версию своего модуля, нельзя проверить его работоспособность.

У меня неймспейс в файле сломал скрипт, который выдал обсфукатор. И ты никак не можешь это проверить не выложив модуль в общий доступ.

Считай все пользователи могут скачать не работающее решение и написать на тебя жалобу)

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

Также предлагаю выводить историю загрузок.

v0.5 - 22.01.2015 21:25 - (увидел, что косяк откатился назад)
v1 - 22.01.2015 21:23
v0.5 - 10.05.2013 21:23
v0.4 - 25.01.2012 22:48
v0.1 - 22.01.2012 22:48

Те например разработчик указывает строчку $APPLICATION->registerAdditionalScript('jquery', SITE_TEMPLATE_PATH . '/js/jquery')

это значит что в дальнейшем запись вида $APPLICATION->showAdditionalScript('jquery') подключит версию jquery разработчика.

Все это уже есть в вордпресс, при огромном количестве плагинов.

Для PHP на https://packagist.org/statistics выложено уже порядка 100 тысяч (!) библиотек, компонентов, бандлов и фреймворков. При разработке проектов, в том числе на Битриксе логично использовать готовые решения, если они помогают в решения задачи. Все подобные пакеты ставятся через Composer, который генерирует файл autoload.php в соответствии с PSR-0.

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

Я видел идею http://idea.1c-bitrix.ru/implement-the-ability-to-install-bitrix-using-composer/, но она про установку битрикса через composer, это как раз не так критично, а вот подключение внешних библиотек в проект было бы очень полезной вещью.

Идея простая - а пусть админ видит, в карточке редактирования элемента, тем или иным способом, символьные коды свойств. Сделать, наверняка, очень просто, а будет облегчение, когда кодов много, да они незнакомые, да еще попереименовывали поля.

если не нашел PHRASE пусть так и пишет PHRASE, а не пустоту

ar,  ob,  db по-моему только мусор добавляют а не читабельность.

Массивы следует именовать с префиксом ar, при этом следующее логическое слово в названии начинается с большой буквы. Например, $arResult, $arModifiedUsers.

Объекты следует именовать с префиксом ob, при этом следующее логическое слово в названии начинается с большой буквы. Например, $obElement, $obUser.

Объект класса CDBResult следует начинать с префикса db, при этом следующее логическое слово в названии начинается с большой буквы. Например, $dbResult.

Раз переходим к ООП, пусть у компонента будет доступно свойство $APPLICATION, которое заменит global $APPLICATION в методах.

И наверно в модули тоже можно.

Dependency injection.

В Redmine есть очень удобная фича - составление планов релизов из задач.
Очень нужна функция при управлении разработкой ПО.

Предлагаю сделать аналогичную возможность.

Конечно есть стикеры, но их можно скрыть, не обратить внимания. А было бы, наверно, не плохо, если перед, например, обновлением появлялось предупреждение, которое заполнялось бы разработчиками, где были бы указаны особенности сайта, на которые может повлиять обновление. Или раздел в админке, где важные моменты по сайту бы хранились, так как поднимать таск менеджеры, переписки и прочее не всегда является возможным. То есть раздел, где разработчик может какой-то комментарий для себя или для других оставить. И одновременно, при создании и разворачивании резервной копии, они бы тоже перемещались вместе с копией сайта

Как я узнал, разные приложения Битрикс24 разработанные одним разработчиком не могут взаимодействовать друг с другом и обмениваться данными. Так например, не получиться получить данные из хранилища (инфоблока) одного и использовать их в другом.

Данный функционал позволил бы делать разные интеграции и дал бы большие вохмодности для развития в направлении разработки приложений +для Битрикс24.