Vitsliputsli

Вы так пишите, будто хотите чтобы вас пожалели и поддержали. Это лучше к близким.

Вы бы стали работать при таких условиях дальше, при том что уже работаете полтора года и такие вещи случается довольно часто?

При условии 30к? Насколько это соответствует вашим навыкам никто здесь не знает.
По поводу просьбы исправить свои косяки в нерабочее время - да, вы не обязаны этого делать в нерабочее время, но и с точки зрения работодателя вы по факту не сделали свою работу в рабочее время. И тем более, если исправление ошибки не ждало рабочего дня. Кто в итоге ее исправил? Вы в рабочий день? Или ваш начальник сам разбирался?
Как вы этот конфликт будете решать зависит от вас, для кого-то это нормально, кому-то это компенсирует зарплата или иные моменты.

Если же хотите не только погрустить, но и что-то делать, то как уже написали, идите на собеседования и от этого уже отталкивайтесь. Менять что-либо всем страшно, но без этого ничего не изменится, подумайте что будет через 5, 10 лет.

Если версия MySQL позволяет, смотрите аналитические функции.
Если нужно на 5.7, то можно применить следующую магию:

select 
        case when @userId<>user_id then @q:=1 else @q:=@q+1 end q,
        case when @q=1 then @userId:=user_id else @userId end user_id
    from (select * users_images order by user_id) t1, (select @userId:=0, @q:=1) t2
    where user_id<>@userId or (user_id=@userId and @q<=2)

Здесь мы получаем из таблицы users_images по 3 элемента в каждой группе по user_id. Лимит установлен в самом конце <=2 - означает 3. Выглядит кошмарно, но решая такие задачи переменными mysql часто получается так.

Исходники проекта, ядра и модулей - это одно. Бизнес-проекты, для которых собираем билды из первых - это иное. Git - это система контроля версий исходного кода, она не занимается решением вопросов бизнеса. Поэтому не стоит через git решать вопросы кому какие модули были проданы.
Если смотреть шире, то пусть разработчики пишут код (в одном репе, в нескольких репах: ядро и модули, как вам удобнее). А в каком виде собирать билд очередному заказчику пусть решают и делают другие люди (а если даже и те же, то все равно в рамках совсем иного процесса).

Зачем? Что вы хотите получить? Что вам не нравится сейчас?
Нет универсальных решений, чтобы все было хорошо, смотреть нужно по ситуации. К примеру, есть ли смысл контейнеризировать, на это вы сможете ответить только сами. Прикиньте плюсы и минусы, стоит ли сейчас тратить на это время, чтобы получить сомнительные (а может и нет) плюсы. Когда для всех разработчиков есть одинаковое готовое окружение - это хорошо, но когда эти все - 2 человека, стоит задуматься.
Насчет схемы, опять же, что вы хотите ей решить, что есть у вас сейчас. Если этой схемой вводите ветку dev - отлично, будет где интегрироваться разработчикам. Сказать, что это должно быть must have - да, но для спринтовой релизной системы, при rolling releases и отсутствии постоянной необходимости интегрироваться - не обязательно.
Если же хочется просто следовать трендам, то по этим вопросам docker и git-flow.

ПМ обычно не пишут ТЗ, т.к. ТЗ - это техническое задание, т.е. подразумевает техническую экспертизу. Если же речь, про некие функциональные требования, то писать обычным человеческим языком, придерживаясь правила писать то, что хотим получить и для чего, а не как это реализовывать. Этого вполне достаточно. Будет ли на основе этих требований формировать ТЗ отдельный специалист или сам разработчик, это вопрос организации компании.
Разработчик - это переводчик с человечьего языка на язык машин, если он не знает одного из языков, то беда. Поэтому этакий разработчик-интроверт, который не умеет общаться, но отлично пишет код, это проблема, т.к. переводчиком он работать не сможет.
Но как бы вы не писали ФТ или даже ТЗ, без коммуникаций во время разработки результат может неприятно удивить, отсюда и стали развиваться различные agile-направления. Насчет "писать обычным человеческим языком" тоже не нужно бросаться в крайности, а то были на моей памяти "одаренные", которые удаляли блок-схемы описывающие бизнес-логику и писали их человеческим языком в меру своих возможностей, это, конечно, уже бред.
Исходя из всего перечисленного, вполне возможно, что ваша проблема не в "правильном" написании ТЗ, а отсутствии коммуникаций и подхода "ничего не знаю, я сделал как в ТЗ" со стороны разработки. Проблема частая, но одним простым советом ее не решить.

Порог входа такой же как везде. В одной компании, как написали "одна рука и один глаз, можно без ног", в другой вас будут спрашивать об инструментах автоматизации и методологиях тестирования.

Но, у одного юзера может быть несколько ID (так устроена система).

Значит это не id юзера. Сделайте реальное id юзера и указывайте его в ваших алиасах. Далее группируйте по реальному id юзера. Либо сделайте таблицу соответствия и группируйте через нее.

Что-то вроде GROUP_BY (users.id = 123 OR users.id = 789).

Это хардкод. Если сейчас вы и решите текущую задачу таким образом, далее будут большие проблемы из-за подобного подхода.

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

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

Куда бы вы размещали шаблоны модуля админки? Вместе со всеми в папке views/layouts или в папке views/layouts/admin, то есть вот если несколько шаблонов для админки, то выделять ли их из шаблонов приложения отдельной папкой, как это сделано в контроллерах и вьюхах?

В директории mymodule/views/layouts. Если это действительно модуль, т.е. отдельный, функционально независимый кусок кода.

Или в операциях == и != что-то не так?

Используйте операторы сравнения === и !==, и сравнивайте с учетом типа переменных.
0 не равен false, но при динамичской типизации, будет произведено приведение типов и затем сравнение.
Чтобы не возникало вопросов, таких как у вас сейчас, сравнивайте однотипные данные, а не предполагая, что будет после динамического приведения типов.

но почему то под нулевым индексом что то есть

Документация по explode:

Если delimiter не содержится в string, и используется отрицательный limit, то будет возвращен пустой массив (array), иначе будет возвращен массив, содержащий string.